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USING A HIGH LEVEL PROGRAMMING processing i6. 32, or 64 bits of informalion or more with a 
LANGUAGE WITH A MICROCONTROLLER single instruction. In contrast to the microprocessor, a micro- 
controller includes a central processing unit, memory and 
Under 35 U.S.C. § 119(e), this application claims benefit other functional elements, all on a single semiconductor 
of prior U.S. provisional application Serial No. 60/029,057, 5 substrate, or integrated circuit (e.g., a "chip"). As compared 
filed Oct. 25, 1996. to the relatively large external memory accessed by the 
A portion of the dLsclosure of thus patent document microprocessor, the typical microcontroller accesses a much 
contains material which is subject to copyright protection. smaller memory. A typical microcontroller can access one to 
The copyright owner has no objection to the facsimile sixty-four kilobytes of built-in memory, with sixteen kilo- 
reproduction by anyone of the patent document or the patent lO bytes being very common. 

disclosure, as it appears in the Patent and Trademark Office There are generally three different types of memory used: 

patent file or records, but otherwise reserves all copyright random access memory (RAM), read only memory (ROM), 

rights whatsoever. and electrically erasable programmable read only memory 

„ „ (EEPROM). In a microcontroller, the amount of each kind 

BACKGROUND OF THE INVENTION ,s li .nemory avaUable is constrained by the amount of space 

This invention relates in general to the field of on the integrated circuit used for each kind of memory, 

programming, and more particularly to using a high level Typically, RAM takes the most space, and is in shortest 

programming language with a smart card or a microcontrol- supply. ROM takes the least space, and is abundant, 

ler. EEPROM is more abundant than RAM, but less than ROM. 

Software applications written in the Java high-level pro- Each kind of memory is suitable for different purposes, 

gramming language have been so designed that an applica- Although ROM is the least expensive, it is suitable only for 

tion written in Java can be run on many different computer data that is unchanging, such as operating system code, 

brands or computer platforms without change. This is EEPROM is useful for storing data that must be retained 

accomplished by the following procedure. /When a Java> when power is removed, but is extremely slow to write, 
application-is- writtenrit~is~compiled"'into "Class" files> RAM can be written and read at high speed, but is expensive 

jcontaining byte codes that are instructionsjbr a hypothetical> and data in RAM is lost when power is removed. A micro- 

(computercalled.a Java Virtua l Macbin e>An implementation processor system typically has relatively little ROM and 

of this virtual machine is written for each platform that is EEPROM, and has 1 to 128 megabytes of RAM, since it is 

supported. When a user wishes to run a particular Java not constrained by what will fit on a single integrated circuit 

application on a selected platforai, the class files compiled '^^ device, and often has access to an external disk memory 

from the desired application is loaded onto the selected system that serves as a large writable, non-volatile storage 

platform. The Java virtual machine for the selected platform area at a lower cost than EEPROM. However, a microcon- 

is run, and interprets the byte codes in the class file, thus troller typically has a smaU RAM of 0.1 to 2.0 K, 2K to 8K 

effectively running the Java application. of EEPROM, and 8K-56K of ROM. 

Java is described in the following references which are Due to the small number of external components required 

hereby incorporated by reference: (1) Arnold, Ken, and and their small size, microcontrollers frequently are used in 

James Gosling, "The Java Programming Language," integrated circuit cards, such as smart cards. Such smart 

Addison-Wesley, 1996; (2) James Gosling, Bill Joy, and Guy cards come in a variety of forms, including contact-based 

Steele, "The Java Language Specification," Sun cards, which must be inserted into a reader to be used, and 

Microsystems, 1996, (web site: hltp://java.sun,com/doc/ contactless cards, which need not be inserted. In fact, 

language_specification); (3) James Gosling and Henry microcontrollers with contactless communication are often 

McGilton, "ITie Java Language Environment: A White embedded into specialized forms, such as watches and rings. 

Paper," Sun Microsystem.s, 1995 (web site: http:// effectively integrating the functionality of a smart card in an 

java.sun.com/doc/language_environment/); and (4) Tim ergonomically attractive manner. 

Lindholm and Frank Yellin, "The Java Virtual Machine Because of the constrained environment, applications for 

Specification," Addison-Wcslcy, 1997. These texts among smart cards are typically written in a low level programming 

many others describe how to program using Java. language (e.g., assembly language) to conserve memory. 

In order for a Java application to run on a specific i^e integrated circuit card is a secure, robust, tamper- 
platform, a Java virtual machine implementation must be jq resistant and portable device for storing data. The integrated 
written that will run within the constraints of the platform, circuit card is the most personal of personal computers 
and a mechanism must be provided for loading the desired because of its small size and because of the hardware and 
Java application on the platform, again keeping within the software data security features unique to the integrated 
constraints of this platform. circuit card. 

Conventional platforms that support Java arc typically 55 The primary task of the integrated circuit card and the 

microprocessor-based computers, with access to relatively microcontroller on the card is to protect the data stored on 

large amounts of memory and hard disk storage space. Such the card. Consequently, since its invention in 1974, inte- 

microprocessor implementations frequently are used in grated circuit card technology has been closely guarded on 
desktop _and personal compjitets^Hgwever, there ~are~no~^v^ihcse same security grounds. The cards were first used by 
/conventionalja va im plcmentations-orumicrocontrollers. as^/;n^Prpnrh banks as debit cards. In this application, before a 

woumj'pjcally-be^ financial transaction based on the card is authorized, the card 

Microcontrollers differ from microprocessors in many user must demonstrate knowledge of a 4-digit personal 

ways. For example, a microprocessor typically has a central identification number (PIN) stored in the card in addition to 

processing unit that requires certain external components being in possession of the card. Any information that might 

(e.g., memory, input controls and output controls) to func- 65 contribute to discovering the PIN number on a lost or stolen 

tion properly. A typical microprocessor can access from a card was blocked from public distribution. In fact, since 

megabyte to a gigabyte of memory, and is capable of nobody could tell what information might be useful in this 
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regard, virtually all information about integrated circuit high level languages.sucb-asJava.and Eiffel, using powerful 

cards was withheld. mainstream program development tools. New applications 

^' Due to the concern for security, applications written for ^ quickly prototyped and downloaded to a smart card 

! integrated circuit cards have unique properties. For example, If °f ^^"^ »^ "^^^ks. Embed- 

cach application typically is idcnUfied with a particular 5 ded systems using microcontrollers can also gam many of 

1 -J n 1- » • II these advantages for downloadmg new applications, hieh 

i owner or identity. Because applications typically are wntten , , ^, , , i • i . . - i_ i 

1 1 . , , , . . .1 level program development, and rapid prototyping by mak- 

m a low-level programming language, such as assembly ^ invendon. & ^ 

lanGuace, the applications are written for a particular type of ^ i . *• r .u • • i j 

■ .i Vv t_ i-i » , . Implementations of the mvention may include one or 

, microcontroUer. Due to the nature of low level programming ^^ore of the foUowing.tThT-mghnE^n^WammiiigllH^ 

" languages, unauthorized applications may access data on the lO -^- ^^^-.^^^.^^^^^^^^^ torm^^ 

integrated circuit card. Programs written for an integrated fand may have a Java programming language format. The . 

circuit card are identified with a particular identity so that if ^processormay-be-a-micrDcontroUeTrAtneast-a~portion of the 

two identities want to perform the same programming memory may be located in the processor. f\ 

^--function there must be two copies of some portions of the application may have been processed from a second 

application on the microcontroller of the integrated circuit 15 app^cation that has a string of characters, and the string of 

card. characters may be represented in the first application by an 

Integrated circuit card systems have historically been identifier (e.g., an integer). \J 

closed systems. An integrated circuit card contained a dedi- The processor may be also configured to receive a request 

cated application that was handcrafted to work with a from a requester (e.g., a processor or a terminal) to access an 

specific terminal application. Security checking when an element (e.g., an application stored in the memory, data 

integrated circuit card was used consisted primarily of stored in the memory or the communicator) of the card, after 
rmaking~sure-that-the-card-applieation-and-the"tenminal-% receipt of the request, interact with the requester to authen- 
Lapplication were a matched pair and that the data on the card J> ^i^ate an identity of the requester, and based on the identity. 

wasvalid- ^ selectively grant access to the element. 

^ As Thc o ularit of inte rated circuit cards rew it memory may also store an access control list for the 

e popu an y o in egra e circui car s S*"^^' ^ element. The access control list furnishes an indication of 

became clear that integrated circmt card usei^ would be ^^^^^^ ^^^^^ ^^^^ 

averse to carrying a different integrated circuit card for each ^^^^ ^^^^^^j j-^j^ processor selectively grams specific 

mtegrated circuit card application. Therefore, multiple coop- types of access (e.g.. reading data, writing data, appending 

erating applications began to be provided on smgle provider 3^ jata, creating data, deleting data or executing an application) 

integrated circuit cards. Thus, for example, an automated ^jjg requester. 

teller machine (ATM) access card and a debit card may -phe application may be one of a several applications 
coexist on a single integrated circuit card platform. stored in the memory. The processor may be further con- 
Nevertheless, this was still a closed system since all the figured to receive a request from a requester to access one of 
applications in the terminal and the card were built by one the plurality of applications; after receipt of the request, 
provider having explicit knowledge of the other providers. determine whether said one of the plurality of applications 
The paucity of information about integrated circuit complies with a predetermined set of rules; and based on the 
cards — particularly information about how to communicate deterroin ation, selectivel y grant access to the requester to 
with them and how to program them — has impeded the <^|d^ne^fjhc_pluraHty^of^ppJicatio^>.T^ 
general application of the integrated circuit card. However, 40 rules provide a guide for determining whether said one of the 
the advent of public digital networking (e.g., the Internet and plurality of applications accesses a predetermined region of 
the World Wide Web) has opened new domains of applica- the memory. The processor may be further configured to 
tion for integrated circuit cards. In particular, this has lead to authenticate an identity of the requester and grant access to 
a need to load new applications on the card that do not have said one of the plurality of applications based on the identity, 
explicit knowledge of the other providers, but without the 45 The processor may be also configured to interact with the 
possibility of compromising the security of the card. terminal via the communicator to authenticate an identity; 
However, typically, this is not practical with conventional determine if the identity has been authenticated; and based 
cards that are programmed using low level languages. on the determination, selectively allow communication 

between the terminal and the integrated circuit card, 
50 The communicator and the terminal may communicate 

In general, in one aspect, the invention features an inte- via communication channels. The processor may also be 

grated circuit card for use with a terminal. The integrated configured to assign one of the communication channels to 

circuit card includes a memory that stores an interpreter and the identity when the processor allows the communication 

an application that has a high level programming language between the terminal and the integrated circuit card. The 

format. A processor of the card is configured to use the 55 processor may also be configured to assign a session key to 

interpreter to interpret the application for execution and to the assigned communication channel and use the session key 

use a communicator of the card to communicate with the when the processor and the terminal communicate via the 

terminal. assigned communication channel. 

Among the advantages of the invention are one or more The terminal may have a card reader, and the communi- 
of the following, yew applica tions may be~downloaded lo"a7 60 cator may include a contact for communicating with the card 

c^smari^card'without^compromising ihe security o^the'sm^ reader. The terminal may have a wireless communication 

*-card?These applications~may'bc provided'by different com- device, and the communicator may include a wireless trans- 

panies loaded at different times using different terminals. ceiver for communicating with the wireless communication 

Security is not compromised since the ap plicatio ns are device. The terminal may have a wireless communication 
protected against unauthorized access of 4ny„appli catio a}65 device, and the communicator may include a wireless trans- 
{code or datF by the~security-features~provided"by~thT"Java^ mitter for communicating with the wireless communication 

iyirtual"machine^Smart"card~applications"can be createdln device. 
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In general, in another aspect, the invention features a municate with the terminal and a memory that stores a first 

method for use with an integrated circuit card and a terminal. application that has been processed from a second applica- 

The method includes storing an interpreter and at least one tion having a jtnng^oLcharactejgJhe string of 'dSaractere^ 

application having a high level programming language for- Qarc"1^ pi^nted ,in.the-fir5l-application,by,anJdcntifier. The 

mat in a memory of the integrated circuit card. A processor 5 integrated circuit card includes a processor that is coupled to 

of the integrated circuit card uses the interpreter to interpret the memory. The processor is configured to use the inter- 

the at least one application for execution, and the processor preter to interpret the first application for execution and to 

uses a communicator of the card when communicating use the communicator to communicate with the terminal, 
between the processor and the terminal. in general, in another aspect, the invention features a 

In general, in another aspect, the invention features a ^0 method for use with an integrated circuit card and a terminal, 

smart card. The smart card includes a memory that stores a The melhodnncludes process ing~F~second-application^lo^ 

Java interpreter and a processor that is configured to use the /create a first application. The second application has a string? 

interpreter to^terpret"a^Java~application"for executiqnT^ ( of characters. The string of characters is represented by anT) 

In general, in^^andlhcTaspectnii^invemioFTSm a Cidentifier in tbe^ second application. An interpTeterahd thej> 

microcontroller that has a semiconductor substrate and a Cfirst~application are storedjn a memory of the integrated* 
memory located in the substrate./A''programminglanguagel Ccircmt^ar^LA.p 

interp reter is sto red in the memofylind is configured to (first ap plicationlQrexecution.^ 
f implem ent security~checks.?A central processing unit is In general, in another aspect, the invention features a 

located in the substrate and is coupled to the memory. microcontroller that includes a memory which stores an 

Implementations of the invention may include one or application and an interpreter, llie application has a class file 

more of the following. ^'e-interpreter may beTJava^bytel format. A processor of the microcontroller is coupled to the 

^code'interpreteTl'he securiry^h^eckslnr>^iiicli^^ memory and is configured to use the interpreter to interpret 

ing-firewalls"and^may include enforcing a sandbox security the application for execution. 

model. In implementations of the invention, the microcontroller 

In general, in another aspect, the invention features a ^ may also include a communicator that is configured to 

(Smart~c afd~tlTat~has a progra m min g~languagejnterprc^^ communicate with a terminal. 

stored'ina-memoly^Mthexard.JJFinte^re^ In general, in another aspect, the invention features a 

ilcrimplement^^security check. A central processing uriifof tfie~ method for use with an integrated circuit card. The method 

lcard~isncoupled"to~the memory. includes storing a first application in a memory of the 

^ In general, in another aspect, the invention features an integrated circuit card, storing a second application in the 

integrated circuit card that is used with a terminal. The card memory of the integrated circuit card, and creating a firewall 

includes ^a"communicalor and~a~memory~that-stores~arn that isolates the first and second applications so that the 

jntefpfeter and^Tirst instructions of a first applic ation .':'The^ second application cannot access either the first application 

(fiisnnsmiaioni^have been converted-fro^ or data associated with the first application, 
(tions^ofj second_appjK^tion^^(T^ circuifcard; In general, in another aspect, the invention features an 

Cjncludcs-a-process orlharis cou pled_to the memory^aridls integrated circuit card for use with a terminal. The integrated 

configured io'uselhe interpreter to execute~tlie"first instruc- circuit card includes a communicator that is configured to 

tions and to communicate with the terminal via the com- communicate with the terminal, a memory and a processor, 

municator. 4q The memory stores applications, and each application has a 

Implementations of the invention may include one or high level programming language format. The memory also 

more of the following. The first and/or second applications stores an interpreter. ITie processor is coupled to the memory 

may have class file format(s). The first and/or second and is configured to: a.) use the interpreter to interpret the 

applications may include byte codes, such as Java byte applications for execution, b.) use the interpreter to create a 

codcs-CTfirBrsfiiismic^^ generalized o Trcnumg ^s firewall to isolate the applications from each other, and c.) 

<bcrcd~vcrsions^ of ~^thc~sccond~iristruct ions. T he second use the communicator to communicate with the terminal, 
inslniclions may incIirde~co"nstant"references, and the first Other advantages and features will become apparent from 

instructions may include constants that replace the constant the following description and from the claims, 
references of the second instructions. The second instruc- 
tions may include references, and the refe rences may shift 50 BRIEF DESCRIPTION OF THE DRAWING 
location during the ^convcrsio'nof the secondln structionsl o3 FIG. 1 is a block diagram of an integrated card system, 
(^the-first-inslruclionsj^llie firsrinstruclions^r^^ PIG 2 is a flow diagram illustrating the preparation of 

tcHhVreferer^^ j^^^ applicalioas to be downloaded to an integrated circuit 

(include byte codes for a first type ot virtuar machine, and incS ^^^^ 

fSecmTdlnstructionFmav^incl ude b yte codes for a second"^55 j ^ . ^ 

\ype of vlOTal ma».The fii^y^is diffi?^trSfi the^ ^ ^}°- ^ a b'ock diagram of the files used and generaled 

— 3- ' . by the card class file converter. 

second type. ^ ^ . 

In general, in another aspect, the invention features a /'^ 4 is a block diagram illustrating the transformation 
method for use with an integrated circuit card, llie method application class file(s) into a card class file, 

includes^converting-second-instructions-of a"se^ ^ ^ diagram illustratmg the working of the 

/cation to' first ins tructions of a jTrsrappli cation; >storing the ^^^ss file converter. 

first instruciionTin a memory oflhelntegraled circuit card; FIG. 6 is a flow diagram illustrating the modification of 

and using an interpreter of the integrated circuit card to the byte codes. 

execute the first instructions. FIG. 7 is a block diagram illustrating the transformation 

In general, in another aspect, the invention features an 65 of specific byte codes into general byte codes, 
integrated circuit for use with a terminal, llie integrated FIG. 8 is a block diagram illustrating the replacement of 

circuit card has a communicator that is configured to com- constant references with constanLs. 
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FIG. 9 is a block diagram illustrating the replacement of communicator i2b. The terminal communicator 12b is a 

references with their updated values. communications device capable of establishing a commu- 

FIG. 10 is a block diagram illustrating renumbering of nications channel between the integrated circuit card 10 and 

original byte codes terminal 14. Some communication options include con- 

no. U is a block diagram illustrating translation of ' ^^^^ '""^^^'^^ ^j^^^^^ communications via radio frc- 

original byte codes for a different virtual machine architec- ^^^^^^ ^"^'^^^^ techniques, seria conQmunication 

j^^^ protocols, packet communication protocols, ISO 7816 com- 

... . , ^. munication protocol, to name a few. 

no. 12 IS a block diagram illustrating loading apphca- ^ . , , • ^ ... 

tions into an integrated circuit card. . ^.'^ can also interact with apphcauons mn- 

r>r^ .7 . .. ... . nine in the integrated circuit card 10. In some cases, different 

no. 13 is a block diagram lUustratmg executing apph- ^^^.^^^^ jjiese purposes. For example, one 

cations in an integrated circuit card. ^-^^ ^^^^^^^1 ^^^^^^^ applications, 

no. 14 is a schematic diagram illustrating memory different terminals could be used to download the 

organization for ROM, RAM and EEPROM. applications, and yet other terminals could be used to run the 

FIG. 15 is a flow diagram illustrating the overall archi- various applications. Terminals can be automated teller 

tecture of the Card Java virtual machine. machines (ATMs), point-of-sale terminals, door security 

FIG. 16 is a flow diagram illustrating method execution in systems, toll payment systems, access control systems, or 

the Card Java virtual machine with the security checks. any other system that communicates with an integrated 

HG. 17 is a flow diagram Ulustrating byte code execution „ ^^^^^^^ ^^'"^ microcontroller, 

in the Card Java virtual machine. ^^^jThe-integrated circuit-card-lO contains a-card Java-^virtual — 

no. 18 is a flow diagram illustrating method execution in CE2EW5i.(C"£ 16^which-i^d-io-interpret-appli— 

the Card Java virtual machine without the security checks. ^'»<='' contained on the card 10. 

no. 19 is a block diagram iUustrating the association , '""^^J' 'h/ Java application 20 includes three 

between card applications and identities. 25 1^^"""^ !f fif ' ^^'7 I ' 

.. .. ^ 20cJThese-source-code-files-are-prepared-and-compiled m as 

FIG. 20 IS a block diagram illustrating the access rights of application development environment 22. When the^ 

a specihc running application. OlvT application 20 is compiled by the developrn^env^r^ 

FIG. 21 is a perspective view of a microcontroller on a ^ronment 22, application class files 24 are produced, with^ 

smart card. these class files A.class 24a, B. class 24/?, and C.class 24c^ 

FIG. 22 is a perspective view of a microcontroller on a i corresponclirigtotKeirTespective cla^sJava^ource code^20flX 

telephone. 207?7^and~2 0crTh e_application class^files 24 follow the\ 

FIG. 23 is a perspective view of a microcontroller on a /sta ndard glagjjgjorm^^ in c hapter_4_orthc> 

key ring. Oava virtual macHine s pecification by Tim Lindholra and 

urn -i/i ,v «^,^«^«f -,,^ «f « ♦-^ii^, « ir Frank Yellin, "The Java Virtual Machine Specification," 

rlO. 24 is a perspective view oi a microcontroller on a 35 ^ , *. ™ ... , 

. AddisoD-Wesley, 1996. (rhese_application-elass~nlcs-24 are. 

i*^ . . . - . :fed-into-lhe-card-class-file convener-26; which consolidates 

HG. 25 is a perspective view of a microcontroller on a Wda)mpressesnhe"filesrprodu-cing a single card class file 

circuit card of an automobile. 27. The card class file 27 is loaded to the integrated circuit 

DETAILED DESCRIPTION OF THE 40 ^^^^ ^ conventional card loader 28. 

PREFERRED EMBODIMENTS Refe rring t o FIG. 3,-^ the card'class-file converier-26 is aj 

Qchss file postprocessor _that processes a set of class fi les 24"\ 

Referring to FIG. 1, an integrated circuit card 10 (e.g., a (that^are^^encoi^^ 

smart card) is constructed to provide a high level, Java- optionally using a strinpo"ID~input'nnap'file"301op^roduce 

based, multiple application programming and execution a Java card class file 27 in a card class file format. One such 

environment. The integrated circuit card 10 has a commu- card class file format is described in Appendix A which is 

nicator 12a that is configured to communicate with a ter- hereby incorporated by reference. In addition, in some 

minal communicator 12^? of a terminal 14. In some embodiments, the card class file converter 26 produces a 

embodiments, the integrated circuit card 10 is a smart card string to ID output map file 32 that is used as input for a 

with an 8 bit microcontroller, 512 bytes of RAM, 4K bytes subsequent execution of the card class file converter. 

ofEEPROM, and 20K of ROM; the terminal communicator in some embodiments in order for the string to ID 

12b is a conventional contact smart card reader; and the mapping to be consistent with a previously generated card 

terminal 14 is a conventional personal computer running the class file (in the case where multiple class files reference the 

Windows NT operating system supporting the personal same strings), the card class file converter 26 can accept 

computer smart card (PC/SC) standard and providing Java 55 previously defined string to ID mappings from a string to ID 

development support. input map file 30. In the absence of such a file, the IDs arc 

In some embodiments, the microcontroller, memory and generated by the card class file converter 26. Appendix B, 

communicator are embedded in a plastic card that has which is hereby incorporated by reference, describes one 

substantially the same dimensions as a typical credit card. In possible way of implementing and producing the string to ID 

other embodiments, the microcontroller, memory and com- ^0 inpul niap file 30 and string to ID output map file 32 and 

municator are mounted within bases other than a plastic illustrates this mapping via an example, 

card, such as jewelry (e.g., watches, rings or bracelets). Referring to HO. 4, a typical application class file 24fl 

automotive equipment, telecommunication equipment (e.g., includes class file information 41; a class constant pool 42; 

subscriber identity module (SIM) cards), security devices class, fields created, interfaces referenced, and method infor- 

(e.g., cryptographic modules) and appliances. ^5 mation 43; and various attribute information 44, as detailed 

llie terminal 14 prepares and downloads Java applica- in aforementioned Java Virtual Machine Specification. Note 

tioas to the integrated circuit card 10 using the terminal that much of the attribute information 44 is not needed for 
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this embodiment and is eliminated 45 by the card class file SourceFile, Constant Value, Exceptions, LineNumberTable, 

coDverter 26. Eliminated attributes include SourceFile, and LocalvariableTable may be safely discarded 45. The 

Constarit Value, Exceptions, LineNumberTable, only attribute that is retained is the Code attribute. The Code 

LocalvariableTable, and any optional vendor attributes. The attribute contains the byte codes that correspond to the 

typical card class file 27 as described in Appendix A is 5 methods in the Java class file 24a. 

derived from the application class files 24 in the following k^^ i*,, .k- ^^a^^ ;«,,^k. .u 

manner. The card class file information 46 is derived from ^ "^"^ ^ "^'te codes 54 mvolves examining the 

the aggregate class file information 41 of all application ^ode aUnbute information 44 for each method m the class 

class mes 24a. 24b, and 24c. The card class file constant ""'''^'"S the operands of byte codes that refer to 

1 vi** • J ■ J r .1. .1 . 1 A'% entries in the Java class file constant pool 42 to reflect the 

pool 47 IS den ved from the aggregate class constant pool 42 m » • • *u j i ci . . ^ ai i 

u 1- 1 n^ -tAL entries m the card class file constant pool 47. In some 

of all application class files 24a, 24d, and 24c. The card ... ..... ^ , _i j ^ 

1 n 1 J * J • . r r J J J • f embodiments, the byte codes are also modified, as described 

class, fields created, interfaces referenced, and method infor- u i 

• . . l^elow 
mation 48 is derived from the aggregate class, fields created, 

interfaces referenced, and method information 43 of aU Modifying the byte codes 54 involves five passes (with 

application class files 24a, 246, and 24c. The card attribute ^wo optional passes) as descnbed by the flowchart in FIG. 6. 

information 49 in this embodiment is derived from only the <^"gi°2l byte codes 60 are found in the Code attribute 44 

code attribute of the aggregate attribute information 44 of aU ^f the Java class file 24a bemg processed. The first pass 61 

application class files 24a, 24^?, and 24c. records all the jumps and their destinations in the original 

To avoid dynamic linking in the card, all the information ^5^^ J^"'?^^ ^ translation some single 

that is distributed across several Java class files 24a, 246, ,0 ^.V^ "^"^^ ""'^ translated to dual or triple bytes, FIG. 7 

and 24c that form the application 24, are coalesced into one ^""ftrates an example wherein byte code ILOAD_0 is 

card class file 27 by the process shown in the flowchart in [^f'^^^ ^y^^* ^^^^ ^^^^ ^'^^ argument 0. 

FIG. 5. The first class file to be processed is selected 51a. ^^en this is done the code size changes requiring adjust- 

The constant pool 42 is compacted Sib in the following mentof any jump destmations which are affected. The re fore, 

manner. All objects, classes, fields, methods referenced in a 25 ^^^""'^^^^"^ transformations are made, the original byte 

Java class file 24a are identified by using strings in the ^^f^ ^"^^7.^^ any jump byte codes and a note 

conslanl pool 42 of the class file 24a. llie card class file made of their position and current destmation. Ilie program 

converter 26 compacts the constant pool 42 found in the Java ^"^^ ^^^S"^^"^ "^^^^^ ^ 'J^ Appendix D shows how these 

class file 24a into an optimized version. Tliis compaction is J^P^ Appendix D is hereby mcorporated by 

achieved by mapping all the strings found in the class file 30 ''^t^r^oce. 

constant pool 42 into integers (the size of which is micro- Once the jumps are recorded, if the optional byte code 

controller architecture dependent). These integers arc also translation is not being performed 62, the card class file 

referred to as IDs. Each ID uniquely identifies a particular converter 26 may proceed to the third pass 64. 

object, class, field or method in the application 20. Otherwise, the card class file converter converts specific 

Therefore, the card class file converter 26 replaces the 35 byte codes into generic byte codes. Typically,'~t he'transrate dl? 

strings in the Java class file constant pool 42 with its ^b ytc'codes are not"inte rpj^tcdlrr thc~Card JVM 'l"6~but~are 

corresponding unique ID. Appendix B shows an example supported by converting the byte codes into equivalent byte 

application HelloSmarlCard.java, with a table below iUus- codes that can be interpreted by the Card JVM 16 (see FIG. 

trating the IDs corresponding to the strings found in the 7), The byte codes 70 may be replaced with another seman- 

constant pool of the class file for this application. V\ic IDs 49 tically equivalent but different byte codes 72. ITiis generally 

used for this example are 16-bit unsigned integers. entails the translation of short single specific byte codes such 

Next, the card class file converter 26 checks for unsup- as ILOAD_0 into their more general versions. For example, 

ported features 51c in the Code attribute of the input Java ILOAD_0 may be replaced by byte code ILOAD with an 
class file 24a. ^ThFCaraTVM~16"only"supports"a"subserof^ argument 0. This translation is done to reduce the number of 
thTfuirJava~byte codes as described in Appendix C, which;^ 45 byte codes translated by the Card JVM 16, consequently 

is"hereby~incorporatal~by"referenceTHencerth"e^^^^ reducing the complexity and code space requirements for the 

file converter 26 checks for unsupported byte codes in the Card JVM 16. The program code fragment marked "C" in 

Code attribute of the Java class file 24a. If any unsupported Appendix D shows how these translations are made. Note 

byte codes are found 52, the card class file converter flags an that such translations increase the size of the resulting byte 

error and stops conversion 53. The program code fragment 50 code and force the re-computation of any jumps which are 

marked "A" in APPENDIX D shows how these spurious affected. 

byte codes are apprehended. Another level of checking can In the third pass 64, the card class file converter rebuilds 

be performed by requiring the standard Java development constant references via elimination of the strings used to 

environment 22 to compile the application 20 with a '-g' denote these constanLs. FIG. 8 shows an example wherein 

flag. Based on the aforementioned Java virtual machine 55 the byte code LDC 80 referring to constant "18" found via 

specification, this option requires the Java compiler to place an index in the Java class file 24a constant pool 42 may be 

information about the variables used in a Java application 20 translated into BIPUSH byte code 82. In this pass the card 

in the LocalvariableTable attribute of the class file 24a. The class file converter 26 modifies the operands to all the byte 

card class file converter 26 uses this information to check if codes that refer to entries in the Java class file constant pool 

the Java class file 24fl references data types not supported by 60 42 to reflect their new location in the card class file constant 

the Java card. pool 47. FIG. 9 shows an example wherein the argument to 

Next, the card class file converter 26 discards aU the a byte code, INVOKESTATIC 90, refers to an entry in the 

unnecessary parts 51c of the Java class file 24a not required Java class file constant pool 42 that is modified to reflect the 

for interpretation. A Java class file 24a stores information new location of that entry in the card class file constant pool 

pertaining to the byte codes in the class file in the Attributes 65 47. llie modified operand 94 shows this transformation, 'llie 

section 44 of the Java class file. Attributes that are not program code fragment marked "D" in Appendix D shows 

required for interpretation by the card JVM 16, such as how these modifications are made. 
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Once the constant references are relinked, if (be optional ating system 122. In the preferred embodiment, the boot- 
byte code modification is not being performed, the card class strap loader is written in Java, and the integrated circuit card 
file converter may proceed to the fifth and final pass 67. 10 includes a Java virtual machine to run this apphcation. A 

Otherwise, the card class file converter modifies the Java implementation of the loading and execuUon c^^^ 
original bytc-codes-intoiaidiffci;cDtisctigeib7^dg^% s 120 is illustrated Appendix E which is hereby incoipo- 

ported birthTTa-rticular-Card-TVM-K-beiiii^-Onr ' V"^ '^^IPS <=°,'"™' 

. *• 1 j-c u • • I u ^ J receives the card class file 26 and produces a Java card 

potential modification renumbers the original byte codes 60 i26x stored in the card file system 126 in the 

into Card JVM 16 byte codes (see FIG. 10). This renum- £pJ^Qf^ „f ^^^^ ^..^ .i,^;, ^.^^ ^^^i,; ,^ j^^^ 

benng causes the byte codes 100 in the original byte codes ^^^^ applications 12d;c, 126>., and 126z can be stored in a 

. .™ !u"T^!,'^^^''^"''^"^ u -^/* single card in this manner. Tlie loading and execution 

code ILOAD recognized by value 21 may be renumbered to jjo supports commands whereby the terminal 14 

be recognized by value 50. THis modification may be done j^^^ application to run immediately, 

for optimizing the type t^ts (al.so known in prior art as Pass „^ ^^^^ ^^^^ 

3 checks) in the Card JVM 16. The program ccxie fragment „ ^ , r-i^^ n 

I ^iiT^»- A J- u 1 . c*u* i<: Reremng to FIG. 13, upon receiving a reset or an e xecu- 

marked "E in Appendix D shows an implementation of this ^5 & *u i j- j . i ^-^^ 

embodiment. Thfe modification may b^ done in order to '°" f m l"^ '".r-"^",^.^'°11: k ' 

reduce the program space required by the Card JVM 16 to ^.^"^ ^^"^ a I ^^ff \ 

* *t. u * J n 11 *u- j c execution at a predetermined method (for example, main) of 
interpret the byte code. Essentially this modification , . i i • i . i ■ i i- 

, '■.^^ u.rt^^A^o *«t^ n,..A T\/\/i jc K,,t^ iu f the selected class in the selected Java Card application 126z. 

regroups the byte codes into Card JVM 16 byte codes so that ^ i ,^.I^M i^ i i_ i i v -t^y^ 

. . ^ . ... J u J on ine Card JVM 16 provides the Java card application 126z 

byte codes with similar ot>erands, results are grouped 20 , f • . • ^-.-^ . • . 

. J u . -1 nrx* i^r L .* access to the underlying card operating system 122, which 

together, and there are no gaps between Card JVM 16 byte u r-r-nnVxx^ . 

J -rn.- 11 .1. I r^TXM . £c * »i l i providcs Capabilities such as I/O, EEPROM support, file 

codes. This allows the Card JVM 16 to efSciently check ^ ^ . 1 j l /i ■ 

o ^ TA/njf ir u * J J i j * « * systems, access control, and other system functions using 

Card JVM 16 byte codes and validate types as It executes. . , , .„ . . , . . i. - . • 

•^'^ native Java methods as illustrated m Appendix F which is 

In some embodiments, the card class file converter modi- hereby incorporated by reference. 

fies the original byte codes 60 into a different set of byte .rv, ,1 ,1 r .* n/c • * 

, ..^..rt- 1 Ine selected Java card application 126z communicates 

codes designed for a dififerenl virtual machine archilecture ^j,^ ^„ appropriate application in the terminal 14 using the 

as shown in FIG. 11. The Java byte code ILOAD 112 communicator 12fl to establish a communication channel to 

°° 1. ^^'if^ J^t'^^l u ^ 'he terminal 14. Data from the communicator 12<7 to the 
Card JVM 16 byte code iLOAD_B 116 to be used on a byte t^^.^oi i^ « ^«««»«;^ot«,^«\,^, m -^.u^ 
, ^ -i . ^ , A .. 30 terminal 14 passes through a communicator dnver 132 in the 
stack 118. An element m a word stack 114 requires aUocat- ^^^^^^^ ^y^,, specifically written to handle the com- 
ing 4 bytes of stack space, whereas an e ement in the byte ^^^^itioDS protocol used by the communicator 12a. The 
stack 118 requires only one byte of stack space. Although j^,^ integrated circuit card driver 134, 
this option may provide an mcrease m execution speed, it ^^j^^ specifically written to address the capabiUties of the 
nsks losing the security features available in the onginal particular integrated circuit card 10 being used, and provides 
^ * high level software services to the terminal application 136. 

Since the previous steps 63, 64 or 66 may have changed the preferred embodiment, this driver would be appro- 

the size of the byte codes 60 the card class file converter 26 p^ate PC/SC Smartcard Service Provider (SSP) software, 

has to relink 67 any jumps which have been effected. Since jfae data then passes to the terminal application 136, which 

the jumps were recorded in the first step 61 of the card class niust handle the capabilities provided by the particular card 

file converter 26, this adjustment is carried out by fixing the application 1262 being run. In this manner, commands and 

jump destinations to their appropriate values, llie program responses pass back and forth between the terminal appU- 

code fragment marked "F" in Appendix D shows how these cation 136 and the selected card application 1262. The 

jumps are fixed. terminal application interacts with the user, receiving com- 

'ITie card class file converter now has modified byte codes 45 mands from the user, some of which are passed to the 

68 that is equivalent to the original byte codes 60 ready for selected Java card application 126^, and receiving responses 

loading. The translation from the Java class file 24fl to the from the Java card application 126z, which are processed 

card class file 27 is now complete. and passed back to the user. 

Referring back to FIG. 5, if more class files 24 remain to Referring to FIG. 14, the Card JVM 16 is an interpreter 
beprocessed55theprevioussteps51fl, 51fe, 51c, 52and54 50 that interprets a card application 126a:. The memory 

are repeated for each remaining class file. The card class file resources in the microcontroller that impact the Card JVM 

converter 26 gathers 56 the maps and modified byte codes 16 are the Card ROM 140, Card RAM 141 and the Card 

for the classes 24 that have been processed, places them as EEPROM 142. The Card ROM 140 is used to store the Card 

an aggregate and generates 57 a card class file 27. If JVM 16 and the card operating system 122. Card ROM 140 
required, the card class file converter 26 generates a string 55 may also be used to store fixed card applications 140^ and 

to ID output map file 32, that contains a list of all the new class libraries 140^?. Loadable applications 141a, 141£> and 

IDs allocated for the strings encountered in the constant pool libraries 141c may also be stored in Card RAM 141. The 

42 of the Java class files 24 during the translation. Card JVM 16 interprets a card application 141a, 141fc, or 

Referring to FIG. 12, the card loader 28 within the 140a. 'ITie Card JVM 16 uses the Card RAM to store the VM 
terminal 14 sends a card class file to the loading and 60 stack 144a and system state variables 144/?. The Card JVM 

execution control 120 within the integrated circuit card 10 16 keeps track of the operations performed via the VM stack 

using standard ISO 7816 commands. The loading and execu- 144a. The objects created by the Card JVM 16 are either on 

tion control 120 with a card operating system 122, which the RAM heap 144c, in the EEPROM heap 146a, or in the 

provides the necessary system resources, including support file system 147. 

for a card file system 124, which can be used to store several 65 All of the heap manipulated by the Card JVM 16 may be 

card applications 126. Many conventional card loaders are stored in the Card RAM 141 as a RAM Heap 144c, or it may 

written in low level languages, supported by the card oper- be distributed across to the Card EEPROM 142 as a 
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EEPROM Heap U6a. Card RAM 141 is also used for 
recording the state of the system stack 148 that is used by 
routines written in the native code of the microcontroller. 
The Card JVM 16 uses the Card EEPROM 142 to store 
application data cither in the EEPROM heap 146fl or in the 5 
file system 147. Application data stored in a file may be 
manipulated via an interface to the card operating system 
122. This interface is provided by a class library I40b stored 
in Card ROM 140, by a loadable class library 141c stored in 
Card EEPROM 142. One such interface is described in lo 
Appendix F. Applications and data in the card are isolated by 
a firewall mechanism 149. 

To cope with the limited resources available on 
microcontrollers, the Card JVM 16 implements a strict 
subset of the Java programming language. Consequently, a ^5 
Java application 20 compiles into a class file that contains a 
strict subset of Java byte codes. This enables application 
programmers to program in this strict subset of Java and still 
maintain compatibility with existing Java Virtual Machines. 
The semantics of the Java byte codes interpreted by the Card 20 
JVM 16 are described in the aforementioned Java X^rtual 
Machine Specification. The subset of byte codes interpreted 
by the Card JVM 16 can be found in Appendix C. The card 
class file converter 26 checks the Java application 20 to 
ensure use of only the features available in this subset and 25 
converts into a form that is understood and interpreted by the 
Card JVM 16. 

In other embodiments, the Card JVM 16 is designed to 
interpret a different set or augmented set of byte codes 116. 
Although a different byte code set might lead to some 
performance improvements, departing from a strict Java 
subset may not be desirable from the point of view of 
security that is present in the original Java byte codes or 
compatibility with mainstream Java development tools. 

All Card JVM 16 applications 126 have a defined entry 
point denoted by a class and a method in the class. This entry 
point is mapped in the string to ID input map 30 and 
assigned by the card class file converter 26. Classes, meth- 
ods and fields within a Java application 20 are assigned IDs 
by the card class file converter 26. For example, the ID 
corresponding to the main application class may be defined 
as FOOl and the ID corresponding to its main method, such 
as "mainQV*' could be defined as F002. 

ITie overall execution architecture of the Card JVM is 
described by the flowchart in FIG. 15. Execution of the Card 
JVM 16 begins at the execution control 120, which chooses 
a card application 126z to execute. It proceeds by finding 
and assigning an entry point 152 (a method) in this card 
application for the Card JVM 16 to interpret. The Card JVM jq 
16 interprets the method 153. If the interpretation proceeds 
successfully 154, the Card JVM 16 reports success 155 
returning control back to the execution control 120. If in the 
course of interpretation 153 the Card JVM 16 encounters an 
unhandled error or exception (typically a resource limitation 55 
or a security violation), the Card JVM 16 stops 156 and 
reports the appropriate error to the terminal 14. 

An essential part of the Card JVM 16 is a subroutine that 
handles the execution of the byte codes. This subroutine is 
described by the flowchart in FIG. 16. Given a method 160 go 
it executes the byte codes in this method. The subroutine 
starts by preparing for the parameters of this method 161. 
'Willis involves setting the VM slack 144a pointer, VM stack 
144^7 frame limits, and setting the program counter to the 
first byte code of the method. 55 

Next, the method Hags are checked 162. If the method is 
flagged native, then the method is actually a call to native 
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method code (subroutine written in the microcontroller's 
native processor code). In this case, the Card JVM 16 
prepares for an efficient call 163 and return to the native code 
subroutine. The parameters to the native method may be 
passed on the VM stack I44a or via the System stack 148. 
The appropriate security checks are made and the native 
method subroutine is called. On return, the result (if any) of 
the native method subroutine is placed on the VM slack 
144a so that it may be accessed by the next byte code to be 
executed. 

The dispatch loop 164 of the Card JVM 16 is then entered. 
The byte code dispatch loop is responsible for preparing, 
executing, and retiring each byte code. The loop terminates 
when it finishes interpreting the byte codes in the method 
160, or when the Card JVM 16 encounters a resource 
limitation or a security violation. 

If a previous byte code caused a branch to be taken 165 
the Card JVM prepares for the branch 165a. The next byte 
code is retrieved 1656. In order to keep the cost of process- 
ing each byte code down, as many common elements such 
as the byte code arguments, length, type are extracted and 
stored. 

To provide the security offered by the security model of 
the programming language, byte codes in the class file must 
be verified and determined conformant to this model, lliese 
checks are typically carried out in prior art by a program 
referred to as the byte code verifier, which operates in four 
passes as described in the Java Virtual Machine Specifica- 
tion. To offer the run-time security that is guaranteed by the 
byte code verifier, the Card JVM 16 must perform the checks 
that pertain to the Pass 3 and Pass 4 of the verifier. This 
checking can be bypassed by the Card JVM 16 if it can be 
guaranteed (which is almost impossible to do) that the byte 
codes 60 interpreted by the Card JVM 16 are secure. At the 
minimum, code security can be maintained as long as object 
references cannot be faked and the VM stack 144a and local 
variable bounds are observed. This requires checking the 
state of the VM stack 144a with respect to the byte code 
being executed. 

To enforce the security model of the programming 
language, a 256-byte table is created as shown in Appendix 
G which is hereby incorporated by reference. This table is 
indexed by the byte code number. This table contains the 
type and length information associated with the indexing 
byte code. It is encoded with the first 5 bits representing 
type, and the last 3 bits representing length. The type and 
length of the byte code is indexed directly from the table by 
the byte code number. This type and length is then used for 
checking as shown in Appendix H which is hereby incor- 
porated by reference. In Appendix H, the checking process 
begins by decoding the length and type from the table in 
Appendix G which is hereby incorporated by reference. ^Vh& 
length is used to increment the program counter. The type is 
used first for pre-execution checking, to insure that the data 
types on the VM stack 144a are correct for the byte code that 
is about to be executed. The 256 bytes of ROM for table 
storage allows the original Java byte codes lo be run in the 
Card JVM 16 and minimizes the changes required lo the 
Java class file to be loaded in the card. Additional Java byte 
codes can be easily supported since it is relatively easy to 
update the appropriate table entries. 

In other embodiments, as shown in FIG. 10, the Java byte 
codes in the method are renumbered in such a manner that 
the byte code type and length information stored in the table 
in Appendix H is implicit in the reordering. Appendix H is 
hereby incorporated by reference. Consequently, the checks 
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that must be performed on the state of the VM stack 144a 
and the byte code being processed does not have to involve 
a table look up. The checks can be performed by set of 
simple comparisons as shown in Appendix I which is hereby 
incorporated by reference. This embodiment is preferable 
when ROM space is at a premium, since it eliminates a 
256-byte table. However adding new byte codes to the set of 
supported byte codes has to be carefully thought out since 
the new byte codes have to fit in the implicit numbering 
scheme of the supported byte codes. 

In another embodiment, the Card JVM 16 chooses not to 
perform any security checks in favor of Card JVM 16 
execution speed. This is illustrated in the flowchart in FIG. 
18. The flow chart in FIG. 18 is the same as that of FIG. 16 
with the security checks removed. This option is not desir- 
able from the point of view of security, unless it can be 
guaranteed that the byte codes are secure. 

The Card JVM 16 may enforce other security checks as 
well. If the byte code may reference a local variable, the 
Card JVM 16 checks if this reference is valid, throwing an 
error if it is not. If the reference is valid, the Card JVM 16 
stores the type of the local variable for future checking. The 
VM stack 144fl pointer is checked to see if it is still in a valid 
range. If not an exception is thrown. The byte code number 
is checked. If it is not supported, an exception is thrown. 

Finally, the byte code itself is dispatched 165d. The byte 
codes translated by the Card JVM 16 are listed in Appendix 
C. The semantics of the byte codes are described in the 
aforementioned Java Virtual Machine Specification with 
regard to the state of the VM stack 144a before and after the 
dispatch of the byte code. Note also that some byte codes 
(the byte codes, INVOKESTATIC, INVOKESPECIAL, 
INVOKENONVIRTUAL and INVOKEVIRTUAL) may 
cause reentry into the Card JVM 16, requiring processing to 
begin at the entry of the subroutine 161. FIG. 17 shows the 
flowchart of the byte code execution routine. The routine is 
given a byte code 171 to execute. The Card JVM 16 executes 
172 the instructions required for the byte code. If in the 
course of executing the Card JVM 16 encounters a resource 
limitation 173, it returns an error 156. This error is returned 
to the terminal 16 by the Card JVM 16. If the byte code 
executes successfully, it returns a success 175, 

After execution, the type of the result is used to set the 
VM stack 144a stale correctly 165e, properly flagging the 
data types on the VM stack 144a. The byte code information 
gathered previously 1656 from the byte code info table is 
used to set the state of the VM stack 144fl in accordance with 
the byte code that just executed. 

In other embodiments, setting the output state of the VM 
stack 144a with respect to the byte code executed is sim- 
plified if the byte code is renumbered. This is shown in 
Appendix I which is hereby incorporated by reference. 

In yet another embodiment, the Card JVM 16 may bypass 
setting the output state of the VM stack 144a in favor of 
Card JVM 16 execution speed. This option is not desirable 
from the point of view of security, unless it can be guaran- 
teed that the byte codes are secure. 

After the byte code has been executed, the byte code is 
retired 165/. ITiis involves popping arguments ofl; the VM 
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To isolate data and applications in the integrated circuit 
card 10 from each other, the integrated circuit card 10 relies 
on the firewall mechanism 149 provided by the Card JVM 
16. Because the Card JVM implements the standard pass 3 
and pass 4 verifier checks, it detects any attempt by an 
application to reference the data or code space used by 
another application, and flag a security error 156. For 
example, conventional low level applications can cast non- 
reference data types into references, thereby enabling access 
to unauthorized memory space, and violating security. With 
this invention, such an attempt by a card appUcation 126z to 
use a non-reference data type as a reference will trigger a 
security violation 156. In conventional Java, this protected 
application environment Ls referred to as the sandbox 
application-interpretation environment. 

However, these firewall facilities do not work indepen- 
dently. In fact, the facilities are overlapping and mutually 
reinforcing with conventional access control lists and 
encryption mechanisms shown in the following table: 
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Taken together, these facilities isolate both data and 
applications on the integrated circuit card 10 and ensure that 
each card application 126 can access only the authorized 
resources of the integrated circuit card 10. 

Referring to FIG, 19, card applications 126ix, 126^, 1262 
can be endowed with specific privileges when the card 
applications 126 execute. These privileges determine, for 
example, which data files the card applications 126 can 
access and what operations the card applications 126 can 
perform on the file system 147. The privileges granted to the 
card applications 126 are normally set at the time that a 
particular card application 1262 is started by the user, 
typically from the terminal 14. 

The integrated circuit card 10 uses cryptographic identi- 
fication verification methods to associate an identity 190 
(e.g., identities 190a, 190^ and 190c) and hence, a set of 
privileges to the execution of the card application 126. The 
association of the specific identity 190c to the card appli- 
cation 1262 is made when the card application 1262 begins 
execution, thus creating a specific running application 200, 
as shown in FIG. 20. The identity 190 is a unique legible text 


string reliably associated with an identity token. The identity 
stack 144a. Once byte code processing Ls completed, the 60 token (e.g., a personal identification number (PIN) or a RS A 


loop 164 is repeated for the next byte code for the method. 

Once the dispatch loop 164 terminates, the VM stack 
144a is emptied 166. This prevents any object references 
filtering down to other Card JVM 16 invocations and 
breaking the Card JVM*s 16 security. Termination 167 of the 
byte code dispatch loop 164 indicates that the Card JVM 16 
has completed executing the requested method. 


private key) is an encryption key. 

Referring to FIG. 20, in order to run a specific card 
application 1262, the identity 190c of the card application 
1262 must be authenticated. The identity 190c is authenti- 
cated by demonstrating knowledge of the identity token 
associated with the identity 190c. 'llierefore, in order to run 
the card application 1262, an agent (e.g., a card holder or 
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another application wishing to run the application) must 
show that it possesses or knows the application's identity- 
defining encryption key. 

One way to demonstrate possession of an encryption key 
is simply to expose the key itself. PIN verification is an 
example of this form of authentication. Another way to 
demonstrate the possession of an encryption key without 
actually exposing the key itself is to show the ability to 
encrypt or decrypt plain text with the key. 


tion is accomplished by including in the identity authenti- 
cation process the exchange of a one-time session key 209 
between the a card application 126z and the terminal appli- 
cation 136. The key 209 is then used to encrypt subsequent 
trafiSc between the authenticating terminal application 136 
and the authenticated card application 1262. Given the 
one-time session key 209, a rogue terminal application can 
neither "listen in" on an authenticated communication 
between the terminal 14 and the integrated circuit card 10, 


1^,.^ « ^««« fi^ ! -^nn ^„ #u« -^t^^,-,*^^ 30 nor can the rogue terminal application "spoof the card 

Thus, a specific running application 20U on the integrated . u ■ a ■ 


circuit card 10 includes a card application 126z plus an 
authenticated identity 190c. No card application 126 can be 
run without both of these elements being in place. Ilie card 
application 12 6z defines data processing operations to be 


application into performing unauthorized operations on its 
behalf. 

Encryption and decryption of card/terminal traffic can be 
handled either by the card operating system 122 or by the 


performed, and the authenticated identity 190c determines card application itself I262 In the former case, the commu 


on what computational objects those operations may be 
performed. For example, a specific application 1262 can 
only access identity C's files 202 in the file system 147 
associated with the specific identity 190c, and the specific 
card application 1262 cannot access other files 204 that are 
associated with identities other than the specific identity 
190c. 

The integrated circuit card 10 may take additional steps to 
ensure application and data isolation. The integrated circuit 
card 10 furnishes three software features sets: authenticated- 
identity access control lists; a Java-based virtual machine; 
and one-time session encryption keys to protect data files, 
application execution, and communication channels, respec- 
tively. Collectively, for one embodiment, these features sets 
provide the application data firewalls 149 for one embodi- 
ment. The following discusses each software feature set and 
then shows how the three sets work together to insure 
application and data isolation on the integrated circuit card 
10. 

An access control list (ACL) is associated with every 
computational object (e.g., a data file or a communication 
channel) on the integrated circuit card 10 that is be 
protected, i.e., to which access is to be controlled. An entry 


nication with the terminal 14 is being encrypted transpar- 
ently to the application, and message traffic arrives 
decrypted in the data space of the application. In the latter 
case, the card application 1262 elects to perform encryption 
20 and decryption to provide an extra layer of security since the 
application could encrypt data as soon as it was created and 
would decrypt data only when it was about to be used. 
Otherwise, the data would remain encrypted with the session 
key 209. 

25 Ilius, the application firewall includes three mutually 
reinforcing software sets. Data files are protected by 
authenticated-identity access control lists. Application 
execution spaces are protected by the Card JVM 16. Com- 
munication channels are protected with one-lime session 
30 encryption keys 209. 

In other embodiments, the above-described techniques are 
used with a microcontroller (such as the processor 12) may 
control devices (e.g., part of an automobile engine) other 
than an integrated circuit card. In these applications, the 
35 microcontroller provides a small platform (i.e., a central 
processing unit, and a memory, both of which are located on 
a semiconductor substrate) for storing and executing high 
level programming languages. Most existing devices and 
new designs that utilize a microcontroller could use this 


on an ACL (for a particular computational object) is in a data ^ invention to provide the ability to program the microcon 


format referred to as an e -tuple: 

typc:identity:pcrmissions 
The type field indicates the type of the following identity (in 
the identity field), e.g., a user (e.g., "John Smith"), or a 


troUer using a high level language, and application of this 
invention to such devices is specifically included. 

The term application includes any program, such as Java 
applications, Java applets, Java aglets, Java servlets, Java 


group. The permissions field indicates a list of operations 45 commlcts, Java components, and other non-Java programs 


(e.g., read, append and update) that can be performed by the 
identity on the computational object. 

As an example, for a data file that has the ACL entry: 

USER:AcmeAirlines:RAU, 
any application whose identity is "AcmeAirlines" can read 
("R"), append ("A") and update ("U") the data file. In 
addition, the ACL may be used selectively to permit the 
creation and deletion of data files. Furthermore, the ACL 
may be used selectively to permit execution of an applica- 
tion. 

Whenever a computational object is accessed by a run- 
ning application 200, the access is intercepted by the Card 
JVM 16 and passed to the card operating system 122, which 
determines if there is an ACL associated with the object. If 
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that can result in class files as described below. 

Class files may have a source other than Java program 
files. Several programming languages other than Java also 
have compilers or assemblers for generating class files from 
their respective source files. For example, the programming 
language Eiffel can be used to generate class files using 
Pirmin Kalberer's "J-EifFel", an Eiffel compiler with JVM 
byte code generation (web site: http://www.spin.ch/ 
-kalberer/jive/index.htm). An Ada 95 lo Java byte code 
translator is described in the following reference 
(incorporated herein by reference): Tafl, S. Tucker, "Pro- 
gramming the Internet in Ada 95", proceedings of Ada 
Europe '96, 1996. Jasmin is a Java byte code assembler that 
can be used to generate class files, as described in the 


there is an associated ACL, then the identity 190c associated 60 following reference (incorporated herein by reference): 


with the running application 200 is matched on the ACL. If 
the identity is not found or if the identity is not penmitted for 
the type of access that is being requested, then the access is 
denied. Otherwise, the access is allowed lo proceed. 

Referring to FIG. 13, to prevent the potential problems 65 
due to the single data path between the integrated circuit 
card 10 and the terminal 14, communication channel isola- 


Meyer, Jon and Troy Downing, "Java Virtual Machine" 
O'Reilly, 1997. Regardless of the source of the class files, 
the above description applies to languages other than Java to 
generate codes to be interpreted. 

FIG. 21 shows an integrated circuit card, or smart card, 
which includes a microcontroller 210 that is mounted to a 
plastic card 212. The plastic card 212 has approximately the 
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same form factor as a typical credit card. The communicator 2. The integrated circuit card of claim 1, wherein the high 

12a can use a contact pad 214 to establish a communication level programming language format comprises a class file 

channel, or the communicator 12a can use a wireless com- format. 

munication system. 3. The integrated circuit card of claim 1 wherein the 

In other embodiments, a microcontroller 210 is mounted 5 processor comprises a microcontroller, 

into a mobile or fixed telephone 220, effectively adding 4, jy^^ integrated circuit card of claim 1 wherein at least 

smart card capabilities to the telephone, as shown in FIG. 22. ^ portion of the memory is located in the processor. 

In these embodiments, the microcontroller 210 is mounted 5 integrated circuit card of claim 1 wherein the high 

on a module (such as a Subscriber Identity Module (SIM)), ,^^^1 programming language format comprises a Java pro- 

for insertion and removal from the telephone 220. gramming language format. 

In other embodiments, a microcontroller 210 is added to g -phe integrated circuit card of claim 1, wherein 

a key ring 230 as shown in FIG. 23. This can be used to application has been processed from a second appli- 

secure access to an automobile that is equipped to recognize ^^^-^^ ^ ^^^^^ ^f program elements, at least 

kc '^^"^230^'''''^^ microcontroller 210 on the ^^^^ ^ ^^^ing of characters, and 

T 1- • 1 L wherein in the first application the String of characters is 

Jewelry such as a watch or rmg 240 can also house a 1 j ■ i_ ^ . c 

. . . . replaced with an identifier. 

microcontroller 210 in an ergonomic manner, as shown in - . ,^ . „:„,.:, „„,^ /: «,u„«;„ 

T-ir^ 'i^ou uj- *. n 1 7. The integrated circuit card of claim 6, wherein the 

FIG. 24. Such embodiments typically use a wireless com- . , . c • 

. . - . Li- u- • identifier comprises an integer. 

mun.cal.on system for eslabhsh.ng a communical.on g ^^^^^ circuil card of claim 1 wherein the 

channel, and are a convenient way to rniplemenl access ^^^^ ^ further configured to; 

control with a minimum of hassle to the user. ^ . ^ ^ , ^ 

FIG. 25 iUustrates a microcontroller 210 mounted in an ^^^^^^^ « '^''^^^ ^ ^° ^" ^^^^^"^ °f 
electrical subsystem 252 of an automobile 254. In this 

embodiment, the microcontroller is used for a variety of receipt of the request, mteract v^ath the requester to 

purposes, such as to controlling access to the automobile, 25 authenticate an identity of the requester; and 

(e.g. checking identity or sobriety before enabling the igni- teased on the identity, selectively grant access to the 

tion system of the automobile), paying tolls via wireless element. 

communication, or interfacing with a global positioning ^' The integrated circuit card of claim 8, wherein the 

system (GPS) to track the location of the automobile, to requester comprises the processor. 

name a few. 3q 1^- The integrated circuit card of claim 8, wherein the 

While specific embodiments of the present invention have requester comprises the terminal, 

been described, various modifications and substitutions will H- The integrated circuit card of claim 8, wherein 

become apparent to one skilled in the art by this disclosure. the element comprises the application stored in the 

Such modifications and substitutions are within the scope of memory, and 

the present invention, and are intended to be covered by the 35 once access is allowed, the requester is configured to use 

appended claims. the application. 

What is claimed is: 12. The integrated circuit card of claim 8, wherein 

1. An integrated circuit card for use with a terminal, the element comprises another application stored in the 

comprising: memory. 

a communicator configured to communicate with the 40 13. 'llie integrated circuit card of claim 8, wherein the 

terminal; element includes data stored in the memory, 

a memory storing: 14. The integrated circuit card of claim 8 wherein the 

an application derived from a program written in a high element comprises the communicator, 

level programming language format wherein the 15. The integrated circuit card of claim 8, wherein the 

application is derived from a program written in a 45 memory also stores an access control list for the element, the 

high level programming language format by first access control list furnishing an indication of types of access 

compiling the program into a compiled form and to be granted to the identity, the processor further configured 

then converting the compiled form into a converted to: 

form, the converting step including at least one step based on the access control list, selectively grant specific 

selected from a group consisting of 50 types of access to the requester. 

recording all jumps and their destinations in the 16. The integrated circuit card of claim 15 wherein the 

original byte codes; types of access include reading data, 

converting specific byte codes into equivalent 17. The integrated circuit card of claim 15 wherein the 

generic byte codes or vice-versa; types of access include writing data, 

modifying byte code operands from references using 55 18. The integrated circuit card of claim 15 wherein the 

identifying strings to references using unique types of access include appending data, 

identifiers; and 19. The integrated circuit card of claim 15 wherein the 

renumbering byte codes in a compiled format to types of access include creating data. 

equivalent byte codes in a format suitable for 20. llie integrated circuit card of claim 15 wherein the 

interpretation; and 60 types of access include deleting data, 

an interpreter operable to interpret such an application 21. The integrated circuit card of claim 15 wherein the 

derived from a program written in a high level types of access include executing an application, 

programming language format; and 22. The integrated circuit card of claim 1, wherein the 

a processor coupled to the memory, the processor con- application is one of a plurality of applications stored in the 

figured to use the interpreter to interpret the application 65 memory, the processor is further configured to: 

for execution and to use the communicator to commu- receive a request from a requester to access one of the 

nicate with the terminal. plurality of applications; 
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after receipt of the request, determine whether said one of 
the plurality of applications complies with a predeter- 
mined set of rules; and 

based on the determination, selectively grant access to the 
requester to said one of the plurality of applications. 

23. The integrated circuit card of claim 22, wherein the 
predetermined rules provide a guide for determining 
whether said one of the plurality of applications accesses a 
predetermined region of the memory. 

24. The integrated circuit card of claim 22, wherein the 
processor is further configured to: 

authenticate an identity of the requester; and 
grant access to said one of the plurality of applications 
based on the identity. 

25. The integrated circuit card of claim 1, wherein the 
processor is further configured to: 

interact with the terminal via the communicator to authen- 
ticate an identity; and 
determine if the identity has been authenticated; and 
based on the determination, selectively allow communi- 
cation between the terminal and the integrated circuit 
card. 

26. The integrated circuit card of claim 25, wherein the 
communicator and the terminal communicate via commu- 
nication channels, the processor further configured to assign 
one of the communication channels to the identity when the 
processor allows the communication between the terminal 
and the integrated circuit card. 

27. The integrated circuit card of claim 26, wherein the 
processor is further configured to: 

assign a session key to said one of the communication 
channels, and 

use the session key when the processor and the terminal 
communicate via said one of the communication chan- 
nels. 

28. The integrated circuit card of claim 1, wherein the 
terminal has a card reader and the communicator comprises 
a contact for communicating with the card reader. 

29. The integrated circuit card of claim 1, wherein the 
terminal has a wireless communication device and the 
communicator a wireless transceiver for communicating 
with the wireless communication device. 

30. The integrated circuit card of claim 1, wherein the 
terminal has a wireless communication device and the 
communicator comprises a wireless transmitter for commu- 
nicating with the wireless communication device. 

31. A method for use with an integrated circuit card and 
a terminal, comprising: 

storing an interpreter operable to interpret programs 
derived from programs written in a high level program- 
ming language and an application derived from a 
program written in a high level programming language 
formal in a memory of the integrated circuit card 
wherein the application is derived from a program 
written in a high level programming language format 
by first compiling the program into a compiled form 
and then converting the compiled form into a converted 
form, the converting step including at least one step 
selected from a group consisting of 
recording all jumps and their destinations in the origi- 
nal byte codes; 
converting specific byte codes into equivalent generic 

byte codes or vice-versa; 
modifying byte code operands from references using 
identifying strings to references using unique iden- 
tifiers; and 
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renumbering byte codes in a compiled formal to 
equivalent byte codes in a format suitable for inter- 
pretation; and 

using a processor of the integrated circuit card to use the 
5 interpreter to interpret the application for execution; 
and 

using a communicator of the card when communicating 
between the processor and the terminal. 

32. The method of claim 31, wherein the high level 
programming language format comprises a class file format. 

33. The method of claim 31, wherein the processor 
comprises a microcontroller. 

34. The method of claim 31, wherein at least a portion of 
the memory is located in the processor. 

35. The method of claim 31, wherein the high level 
programming language format comprises a Java program- 
ming language format. 

36. The method of claim 31, wherein 

the application has been processed from a second apph- 
cation having a plurality of program elements, at least 
one being a string of characters, further comprising: 
replacing the string of characters in the first application 
with an identifier. 

37. The method of claim 36, wherein the identifier 
includes an integer. 

38. The method of claim 31, further comprising: 
receiving a request from a requester to access an element 

of the card; 

3Q after receipt of the request, interacting with the requester 
to authenticate an identity of the requester; and 
based on the identity, selectively granting access to the 
element. 

39. The method of claim 38, wherein the requester com- 
35 prises the processor. 

40. The method of claim 38, wherein the requester com- 
prises the terminal. 

41. The method of claim 38, wherein the element com- 
prises the application stored in the memory, further com- 

40 prising: 

once access is allowed, using the application with the 
requester. 

42. The method of claim 38, wherein the element com- 
prises another application stored in the memory. 

45 43. The method of claim 38, wherein the element includes 
data stored in the memory. 

44. The method of claim 38, wherein the element com- 
prises the communicator, 

45. The method of claim 38, wherein the memory also 
50 stores an access control list for the element, the access 

control list furnishing an indication of types of access to be 
granted to the identity, further comprising: 

based on the access control list, using the processor to 
selectively grant specific types of access to the 
55 requester. 

46. The method of claim 45, wherein the types of access 
include reading data. 

47. The method of claim 45, wherein the types of access 
include writing data. 

60 48. The method of claim 45, wherein the types of access 
include appending data. 

49. The method of claim 45, wherein the types of access 
include creating data. 

50. The method of claim 45, wherein the types of access 
65 include deleting data. 

51. The method of claim 45, wherein the types of access 
including executing an application. 
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52. The method of claim 31, wherein the application is 
one of a plurality of applications stored in the memory, 
further comprising: 

receiving a request from a requester to access one of the 
applications stored in the memory; 5 

upon receipt of the request, determining whether said one 
of the plurality of applications complies with a prede- 
termined set of rules; and 

based on the determining, selectively granting access to 
the said one of the plurality of applications. jo 

53. The method of claim 52, wherein the predetermined 
rules provide a guide for determining whether said one of the 
plurality of applications accesses a predetermined region of 
the memory. 

54. The method of claim 52, further comprising: 55 
authenticating an indentity of the requester; and 

based on the indentity, granting access to said one of the 
plurality of applications. 

55. The method of claim 31, further comprising: 
communicating with the terminal to authenticate an iden- 20 

tity; 

determining if the identity has been authenticated; and 
based on the determining, selectively allowing commu- 
nication between the terminal and the integrated circuit 
card. 2^ 

56. The method of claim 55, further comprising: 
communicating between the terminal and the processor 

via communication channels; and 
assigning one of the communication channels to the 
identity when the allowing allows communication 
between the card reader and the integrated circuit card. 

57. llie method of claim 56, further comprising: 
assigning a session key to said one of the communication 

channels; and 

using the session key when the processor and the terminal 
communicate via said one of the communication chan- 
nels. 

58. A microcontroller comprising: 

a memory storing: 40 
a derivative application derived from an application 
having a class file format wherein the application is 
derived from an application having a class file format 
by first compiling the application having a class file 
format into a compiled form and then converting the 45 
compiled form into a converted form, the converting 
step including at least one step selected from a group 
consisting of 

recording all jumps and their destinations in the origi- 
nal byte codes; 50 

converting specific byte codes into equivalent generic 
byte codes or vice-versa; 

modifying byte code operands from references using 
identifying strings to references using unique iden- 
tifiers; and 55 

renumbering byte codes in a compiled format to 
equivalent byte codes in a format suitable for 
interpretation, and 

an interpreter configured to interpret applications 
derived from applications having a class file formal; go 
and 

a processor coupled to the memory, the processor con- 
figured to use the interpreter to interpret the derivative 
application for execution. 

59. The microcontroller of claim 58, further comprising: $5 
a communicator configured to communicate with a ter- 
minal. 


60. The microcontroller of claim 59, wherein the terminal 
has a card reader and the communicator comprises a contact 
for communicating with the card reader. 

61. The microcontroller of claim 59, wherein the terminal 
has a wireless communicator and a wireless transceiver for 
communicating with the wireless communication device. 

62. TTie microcontroller of claim 59, wherein the terminal 
has a wireless communication device and the communicator 
comprises a wireless transmitter for communicating with the 
wireless communication device. 

63. The microcontroller of claim 58, wherein the class file 
format comprises a Java class file format. 

64. An integrated circuit card for use with a terminal, 
comprising: 

a communicator configured to communicate with the 

terminal; 
a memory storing: 

applications, each application derived from applica- 
tions having a high level programming language 
format, and 

an interpreter operable to interpret applications derived 
from applications having a high level programming 
language format wherein the apphcation is derived 
from a program written in a high level programming 
language format by first compiling the program into 
a compiled form and then converting the compiled 
form into a converted form, the converting step 
including at least one step selected from a group 
consisting of 

recording all jumps and their destinations in the 

original byte codes; 
converting specific byte codes into equivalent 

generic byte codes or vice -versa; 
modifying byte code operands from references using 

identifying strings to references using unique 

identifiers; and 
renumbering byte codes in a compiled format to 

equivalent byte codes in a format suitable for 

interpretation; and 
a processor coupled to the memory, the processor con- 
figured to: 

a. ) use the interpreter to interpret the applications for 
execution, 

b. ) use the interpreter to create a firewall to isolate the 
applications from each other, and 

c. ) use the communicator to communicate with the 
terminal. 

65. A microcontroller having a set of resource constraints 
and comprising: 

a memory, and 

an interpreter loaded in memory and operable within the 
set of resource constraints, the microcontroller having: 
at least one application loaded in the memory to be 
interpreted by the interpreter, wherein the at least one 
application is generated by a programming environ- 
ment comprising: 

a) a compiler for compiling application source pro- 
grams written in high level language source code 
form into a compiled form, and 

b) a converter for post processing the compiled form 
into a minimized form suitable for interpretation 
within the set of resource constraints by the 
interpreter, wherein the converter comprises means 
for translating from the byte codes in the compiled 
form to byte codes in a formal suitable for interpre- 
tation by the interpreter by: 
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a) using at least one step in a process including the 
steps: 

a.l) recording all jumps and their destinations in 
the original byte codes; 

a.2) converting specific byie codes into equiva- 
lent generic byte codes or vice-versa; 

a.3) modifying byte a)de operands from refer- 
ences using identifying strings to references 
using unique identifiers; and 

a.4) renumbering byte codes in the compiled 
form to equivalent byte codes in the format 
suitable for interpretation; and 

b) relinking jumps for which destination address is 
effected by conversion step a.l, a.2, a3, or a.4. 

66. The microcontroller of claim 65, wherein the com- 
piled form includes attributes, and the converter comprises 
a means for including attributes required by the interpreter 
while not including the attributes not required by the inter- 
preter. 

67. ^rhe microcontroller of claim 65 wherein the compiled 
form is in a standard Java class file format and the converter 
accepts as input the compiled form in the standard Java class 
file format and produces output in a form suitable for 
interpretation by the interpreter. 

68. The microcontroller of claim 65 wherein the compiled 
form includes associating an identifying string for objects, 
classes, fields, or methods, and the converter comprises a 
means for mapping such strings to unique identifiers. 

69. The microcontroller of claim 68 wherein each unique 
identifier is an integer. 

70. The microcontroller of claim 68 wherein the mapping 
of strings to unique identifiers is stored in a string to 
identifier map file. 

71. The microcontroller of claim 65 where in the high 
level language supports a first set of features and a first set 
of data types and the interpreter supports a subset of the first 
set of features and a subset of the first set of data types, and 
wherein the converter verifies that the compiled form only 
contains features in the subset of the first set of features and 
only contains data types in the subset of the first set of data 
types. 

72. The microcontroller of claim 65 wherein the applica- 
tion program is compiled into a compiled form for which 
resources required to execute or interpret the compiled form 
exceed those available on the microcontroller. 

73. 'llie microcontroller of claim 65 wherein the compiled 
form is designed for portability on different computer plat- 
forms. 

74. The microcontroller of claim 65 wherein the inter- 
preter is further configured to determine, during an inter- 
pretation of an application, whether the application meets a 
security criteria selected from a set of rules containing at 
least one rule selected from the set: 

not allowing the application access to unauthorized por- 
tions of memory, 

not allowing the application access to unauthorized 
microcontroller resources, 

wherein the application is composed of byte codes and 
checking a plurality of byte codes at least once prior to 
execution to verify that execution of the byte codes 
does not violate a security constraint. 

75. The microcontroller of claim 65 wherein at least one 
application program is generated by a process including the 
steps of: 

prior to loading the application verifying that the appfi- 

cation does not violate any security constraints; and 
loading the application in a secure manner. 
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76. The microcontroller of claim 75 wherein the step of 
loading in a secure manner comprises the step of: 
verifying that the loading identity has permission to load 
applications onto the microcontroller. 
5 77. The microcontroller of claim 75 wherein the step of 
loading in a secure manner comprises the step of: 
encrypting the application to be loaded using a loading 
key. 

78. A method of programming a microcontroller having a 
memory and a processor operating according to a set of 
resource constraints, the method comprising the steps of: 

inputting an application program in a first programming 
language; 

15 compiling the application program in the first program- 
ming language into a first intermediate code associated 
with the first programming language, wherein the first 
intermediate code being intcrpretable by at least one 
first intermediate code virtual machine; 

20 converting the first intermediate code into a second inter- 
mediate code, wherein the step of converting com- 
prises: 

at least one of the steps of: 

a) recording all jumps and their destinations in the 
25 original byte codes; 

b) converting specific byte codes into equivalent 
generic byte codes or vice -versa; 

c) modifying byte code operands from references 
using identifying strings to references using 

30 unique identifiers; and 

d) renumbering byte codes in a compiled format to 
equivalent byte codes in a format suitable for 
interpretation; and 

relinking jumps for which destination address is effected 
35 by conversion step a), b), c), or d); 

wherein the second intermediate code is intcrpretable 
within the set of resource constraints by at least one 
second intermediate code virtual machine; and 

loading the second intermediate code into the memory of 
the microcontroller. 

79. The method of programming a microcontroller of 
claim 78 wherein the step of converting further comprises: 

associating an identifying string for objects, classes, 
fields, or methods; and 

45 

mapping such strings to unique identifiers. 

80. The method of claim 79 wherein the step of mapping 
comprises the step of mapping strings to integers. 

81. The method of claim 80 wherein the step of loading 
5Q the second intermediate code into the memory of the micro- 
controller further comprises checking the second interme- 
diate code prior to loading the second intermediate code to 
verify that the second intermediate code meets a predefined 
integrity check and that loading is performed according to a 

55 security protocol. 

82. The method of claim 81 wherein the security protocol 
requires that a particular identity must be validated to permit 
loading prior to the loading of the second intermediate code. 

83. ITie method of claim 81 further characterized by 
gQ providing a decryption key and wherein the security proto- 
col requires that the second intermediate code is encrypted 
using a loading key corresponding to the decryption key. 

84. An integrated circuit card for use with a terminal, 
comprising: 

65 a communicator configured to communicate with the 
terminal; 
a memory storing: 
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an application derived from a program written in a high 
level programraing language format wherein the 
application is derived from a program written in a 
high level programming language format by first 
compiling the program into a compiled form and 5 
then converting the compiled form into a converted 
form, the converting step including the steps of: 
modifying byte code operands from references using 
identifying strings to references using unique 
identifiers; lO 
recording all jumps and their destinations in the 

original byte codes; 
converting specific byte codes into equivalent 

generic byte codes or vice-versa; and 
renumbering byte codes in a compiled format to is 
equivalent byte codes in a format suitable for 
interpretation; and 
an interpreter operable to interpret such an applica- 
tion derived from a program written in a high level 
programming language format; and 20 
a processor coupled to the memory, the processor con- 
figured to use the interpreter to interpret the application 
for execution and to use the communicator to commu- 
nicate with the terminal. 

85. A method for use with an integrated circuit card and ^5 
a terminal, comprising: 

storing an interpreter operable to interpret programs 
derived from programs written in a high level program- 
ming language and an application derived from a 
program written in a high level programming language 
format in a memory of the integrated circuit card 
wherein the application is derived from a program 
written in a high level programming language format 
by first compiling the program into a compiled form 
and then convening the compiled form into a converted 
form, the converting step including: 
modifying byte code operands from references using 
identifying strings to references using unique iden- 
tifiers; 

recording all jumps and their destinations in the origi- 
nal byte codes; 

converting specific byte codes into equivalent generic 
byte codes or vice -versa; and 

renumbering byte codes in a compiled formal to 
equivalent byte codes in a format suitable for inter- 
pretation; 

using a processor of the integrated circuit card to use the 
interpreter to interpret the application for execution; 
and 

using a communicator of the card when communicating 
between the processor and the terminal. 

86. An integrated circuit card for use with a terminal, 
comprising: 

a communicator configured to communicate with the ss 
terminal; 
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a memory storing: 

applications, each application derived from applica- 
tions having a high level programming language 
format, and 

an interpreter operable to interpret applications 
derived from applications having a high level 
programming language format wherein the appli- 
cation is derived from a program written in a high 
level programming language format by first com- 
piling the program into a compiled form and then 
converting the compiled form into a converted 
form, the converting step including the steps of: 
modifying byte code operands from references 
using identifying strings to references using 
unique identifiers; 
recording all jumps and their destinations in the 

original byte codes; 
converting specific byte codes into equivalent 

generic byte codes or vice-versa; and 
renumbering byte codes in a compiled format to 
equivalent byte codes in a format suitable for 
interpretation; and 
a processor coupled to the memory, the processor con- 
figured to: 

a. ) use the interpreter to interpret the applications for 
execution, 

b. ) use the interpreter to create a firewall to isolate the 
applications from each other, and 

c. ) use the communicator to communicate with the 
terminal. 

87. A microcontroller comprising: 
a memory storing: 

a derivative application derived frona an application hav- 
ing a class file format wherein the application is derived 
from an application having a class file format by first 
compiling the application having a class file format into 
a compiled form and then converting the compiled 
form into a converted form, the converting step includ- 
ing: 

recording all jumps and their destinations in the origi- 
nal byte codes; 

converting specific byte codes into equivalent generic 
byte codes or vice-versa; and 

renumbering byte codes in a compiled format to 
equivalent byte codes in a format suitable for 
interpretation, and 

an interpreter configured to interpret applications 
derived from applications having a class file format; 
and 

a processor coupled to the memory, the processor con- 
figured to use the interpreter to interpret the derivative 
application for execution. 
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[57] ABSTRACT 

A method and apparatus for securely writing confidential 
data from an issuerer to a customer smart card at a remote 
location includes, establishing a communication link 
between a retailer data terminal device at the remote location 
and the issuer's secure computer. A communication link is 
established between a secure terminal device, which 
includes a smart card reader/writer, and the data terminal 
device. The retailer is authenticated to the issuer and the 
issuer to the retailer by means of a retailer smart card 
presented to the secure terminal device. A session key is 
established for enciphering data traffic between the secure 
terminal device and the issuer's computer using the retailer 
smart card. The customer smart card is presented to the 
secure terminal device. Confidential customer data is enci- 
phered using the session key and it is written from the 
issuer's computer to the customer smart card. 

10 Claims, 4 Drawing Sheets 
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METHOD AND SYSTEM FOR SECURE, 
DECENTRALIZED PERSONALIZATION OF 
SMART CARDS 

5 

TECHNICAL FIELD 

This invention concerns a method for securely writing 
confidential data to smart cards in remote, insecure loca- 
tions. In a second aspect the invention concerns a system for 
securely writing the confidential data. Smart Cards are used 
as a highly-secure means of storing data in a portable form. 
They are of particular use, for example, in cryptographic 
applications for the storage of cipher keys. 

15 

BACKGROUND OF THE INVENTION 

When a smart card is manufactured, the manufacturer 
'bums in* a unique identifying serial number. In addition the 
manufacturer installs a manufacturer's 'Master' Secret 20 
Code. 

The card and the Master Secret Code are subsequently 
conveyed to the Issuer by separate means. Upon receipt by 
the Issuer the card is accessed by presenting the Master 
Secret Code and that code is then changed to a fresh 'Issuer' ^5 
Secret Code not known to the manufacturer. One or more 
User Secret Codes are then stored in the card and used to 
protect access to confidential user data. Initial user data may 
then be stored in the card. The card and the User Secret 
Code(s) are ultimately conveyed to a user by separate 
means, and the appropriate User Secret Code(s) must be 
correctly presented to the smart card by the user, before 
access to the card is allowed. 

The process of presentation of the Master Secret Code, 
storage of the Issuer Secret Code, storage of the User Secret 
Codes, and initial storage of user data, is commonly called 
Personalisation, and is traditionally done in a sectire "Per- 
sonalisation Centre" by the Issuer. This approach is costly, 
time-consuming and relatively insecure. ^ 

SUMMARY OF THE INVENTION 

According to the present invention, as currently envis- 
aged, there is provided a method for securely writing con- 45 
fideniial data from an Issuer to a customer smart card at a 
remote location, comprising the steps of: 
establishing a communications link between a retailer data 

terminal device at the remote location and the Issuer's 

secure computer; 50 
establishing a communications link between a secure temii- 

nal device, which includes a smart card reader/writer, and 

the data terminal device; 
authenticating the retailer to the Issuer and the Issuer to the 

retailer, by means of a retailer smart card presented to the 55 

secure terminal device; 
establishing a session key for enciphering data traffic 

between the secure terminal device and the Issuer's 

computer, using the retailer smart card; 
presenting the customer smart card to the secure terminal 60 

device; then 

enciphering the confidential data under the session key and 
writing it from the Issuer's computer to the customer 
smart card. 

Preferably the method includes the step of establishing a 65 
second session key for enciphering data traffic between the 
data terminal device and the Issuer's computer. 


2 

Preferably the retailer is authenticated to the Issuer by 
entering a retailer secret code which is checked by the 
retailer smart card, then a cipher key is read from the retailer 
smart card to the secure terminal device and checked by a 
challenge sent by the Issuer. Optionally the Issuer is subse- 
quently authenticated to the retailer using a cipher key which 
is read from the retailer smart card to the secure terminal 
device and used to challenge the Issuer. 

Preferably the session keys are established by using a 
cipher key to encrypt the combined product of two random 
numbers, one of which was generated by the first party and 
sent to the second party, the other of which was generated by 
the second party and sent to the first party. 

Advantageously the confidential data is an Issuer Secret 
Code present in the customer smart card to prevent access to 
the card, and required to open the card to accept data. 

Preferably the confidential data comprises a directory and 
file structures, and data. 

According to a further aspect of the invention, as currcndy 
envisaged, there is provided a system for securely writing 
confidential data from an Issuer to a customer smart card in 
a remote location, comprising: 

the Issuer's secure computer; 

a retailer data terminal device at the remote location 
selectively in communication with the computer by 
means of a communications link; 

a secure terminal device at the remote location, including 
a smart card reader/writer, selectively in communica- 
tion with the computer via the data terminal device; 

a retailer smart card containing the data required to 
authenticate the retailer to the Issuer and the Issuer to 
the retailer, and the data required to establish a session 
key for enciphering traffic between the secure terminal 
device and the Issuer's computer; 

a customer smart card able to accept the confidential data, 
when presented to the secure temiinal device, written 
from the computer enciphered under the session key. 

Preferably the retailer smart card also contains the data 
required to establish a second session key for enciphering 
traffic between the data terminal device and the Issuer's 
computer. 

Preferably the confidential data is an Issuer Secret Code, 
present in the customer smart card to prevent access to the 
card, and required to open the card to accept data. 

This method and system permit personalisation of the 
smart card at a location convenient to the customer, such as 
the point of sale of the item, or service, with which the smart 
card is subsequently to be used. Such locations are unlikely 
to be secure, may be widely dispersed from any central 
administrative cenure, and may be operated by staff who do 
not work for the Card Issuer. Furthermore the method 
provides a decentralised personalisation service in a manner 
that ensures the security of all confidential data transferred 
between components of the system. 

As smart cards are used more widely in mass consumer 
applications such as mobile telephony and Pay TV, the high 
volume of smart cards issued, and the widely dispersed 
customer population will make decentralised personalisation 
highly cost-effective and competitive. 

Once the infrastructure for a decenu^lised personalisation 
system is in place, it can be used for securely loading data 
other than personalisation data into previously personalised 
smart cards. 
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FIG. 1 is a schematic diagram showing the relationships 
between the components of a system according to the 
invention. ^ 

FIG. 2 is a schematic flow chart showing the steps of the 
method of writing confidential information from an issuer's 
secure computer to a customer smart card at a remote 
location up to authentication of the retailer; 

FIG. 3 is a schematic flow chart showing the steps of the lo 
method of writing confidential information from an issuer's 
secure computer to a customer smart card at a remote 
location up to enciphered data transfer between the customer 
smart card and the secure computer; and 

FIG. 4 is a block diagram of the secure terminal device is 
STE7. 

DESCRIPTION OF THE PREFERRED 
EMBODIMENT 

Method and system 1 involve the interaction of three 20 
entities: 

The Issuer 2 is the organisation which ultimately provides 
the goods or services that are obtained through the use of the 
customer smart card. It is responsible for the system as a 
whole, for the purchase of smart cards, and for their supply ^5 
to Retailers. This oi^ganisation could be the central office of 
a bank, or a telecommunications operator, for example. 

The Retailer 3 is the institution which represents the 
Issuer 2 in a particular local area. It could be a bank branch, 
or a newsagent, for example. 

The Customer 4 is the end-user of the service, and the 
holder of the smart card that gives access to that service. 

The elements involved in the process of decentralised 
personalisation are: 35 
A Central AdminisU^tion System 5 (ADS). 

A computer system in a secure location that is equipped 
to communicate by telecommunications links with the other, 
remotely sited, components of the system. These links are 
assumed to be insecure. The system 5 also includes a secure 40 
database of Retailer Keys. 
A Data Terminal Device 6 (DTD). 

A small computer system (such as a Personal Computer) 
located in the Retailer's premises. It is equipped to commu- 
nicate, by a telecommunications link, with the CenU-al 45 
Administration System. This system is not considered to be 
secure by the Issuer. 
A Secure Tenninal Device 7 (STE). 

A tamper-resistant, programmable device comprising a 
numeric and function keypad, a display, and a smart card so 
reader/writer. It communicates with the Data Terminal 
device 6 by a serial communications link. 

FIG. 4 is a block diagram of the secure terminal device 
STE7, That device includes a tamper-resistant program- 
mable device 90 which in turn receives information from a 55 
key pad 92, displays information on a display 94 and is 
coupled to a smart card read/writer 96. It communicates with 
a data terminal device DTE6 via a serial communications 
link. 

Smart Cards or Integrated Circuit Cards (ICC). 60 

These are read and written to by the Secure Tenninal 
device. Two categories of smart card are used within the 
system: 


Retailer Cards 8 

Each Retailer is issued with one Retailer Card, which has 
already been securely personalised by the Issuer. It 
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contains the data required to gain access to, and use, the 
system. This data is protected from access by several 
Secret Codes, some known only to the Retailer, and 
some known only to the Centri AdminisUBtion Sys- 
tem. 


Customer Smart Cards 9 

These are the smart cards that will be issued by the 
Retailer 3 to his Customers 4. They are held in stock 
in an unpersonalised state, exactly as they were 
shipped from the card manufacturer. 
The operation of the method and system will be described 

by analysing each phase in the personalisation of a Customer 

smart card from the perspective of the Retailer. These phases 

are identified as: 

Session Establishment; 

Personalisation of Customer Smart Card; 

Session Termination; 

Modification of Data on Customer Smart Cards. 

In general, there are several different operations involved 
in each phase. 
Session Establishment 

1) Retailer System Startup 

On startup, the Data Terminal device sets up a commu- 
nications liiJc with the Central Administration System. This 
link is used for ail future conmiunications between the 
Central Administration System and the Data Terminal 
device. 

2) Retailer Sign-On 

. Once the conmiunications link is established, the Retailer 
is prompted to insert his Retailer Card in the Secure Termi- 
nal device. The Retailer is then prompted by the Secure 
Terminal device to enter his personal Secret Code which is 
passed directly to the smart card for checking. 

3) Retailer Authentication 

If the check of the Retailer's Secret Code succeeds, the 
Secure Terminal device reads a unique unprotected, read- 
only serial number from the smart card, and sends it to the 
Central Administration System via the Data Tferminal 
device. Thus the Admirustraiion System knows which smart 
card is in use. 

The Secure Terminal device then reads a unique cipher 
key out of a file on the smart card which was set up during 
personalisation so that it can only be read after the Retailer's 
Secret Code has been correctly presented. 

The Central Administration. System then sends a random 
number (a challenge) to the Secure Temiinal device, via the 
Data Terminal device. The Secure Terminal device enciphers 
the challenge using the cipher key read from the smart card 
and sends the result (the response) back to the Central 
Administration System. Since the Central Administration 
System maintains a record of the keys held on every Retailer 
Card issued, it is able to validate the response by also 
enciphering the random number challenge using the same 
cipher key, and comparing the result with the response 
received from the Secure Terminal device. If the two values 
are identical, the Retailer has successfully authenticated 
himself to the Genual Administrative System. 

With respect to FIG. 2, a retailer small card CI is inserted 
into the secure terminal device. In a step 20, the retailer 
enters a personal security code which in a step 22 is 
compared to a secret code read from the retailer card CI in 
a step 24. If the codes do not correspond, the terminal rejects 
the card CI in a step 26. If the two codes do correspond, the 
terminal issues an unlock command in a step 28 and reads 
a unique, unprotected, read-only serial number from the card 
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CI in a step 30 and transmits that number to the issuer's the smart card is then communicated to the Central Admin- 
secure computer. In a step 32 the issuer's secure computer isiralion System, either by the Retailer entering identiJying 
retrieves a cipher key 34 associated with the serial number information into the Data Terminal device, or by the Secure 
of the card CI and in a random number generator 36 Terminal device reading a Serial Number out of the smart 
generates a random number RNl. The random number RNl 5 card and sending it to the Central Administration System, 
is then enciphered in a step 38. The random number RNl is 9) Presentation of Manufacturer's Master Secret Code 
also transmitted to the secure terminal device and is enci- At this stage, the smart card is protected from general 
phered in a step 40 using a cipher key 42 carried by the smart access by a unique Master Secret Code written into it by the 
card CI. The enciphered output from the secure terminal manufacmrer. The method by which the Master Secret Code 
device is then transmitted back to the secure computer and lO can be computed for any smart card in a batch will have been 
compared in a step 44 to the output of the local enciphering separately communicated to the Card Issuer. In order to gain 
step 38. If there is no match, the transaction will be rejected access to the smart card, its Master Secret Code must be 
in a step 46. If there is a match, the retailer will be presented and this is done by computing the Master Secret 
authenticated in a step 48. Code in the Central Administration System then sending it 

4) Issuer Authentication 15 to the Secure Terminal device, enciphered under the Central 
Authentication of the Retailer only provides part of the Administration System-Secure Terminal device session key 

security needed. It is equally important to ensure that the 10. In the Secure. Terminal device, it is deciphered and 

Centra] Administradon System is authentic. This is achieved presented to the smart card. This has the effect of opening up 

by performing an enciphered challenge-response in the the smart card for further accesses, 

reverse direction using a random data challenge generated 20 10) Smart Card Set Up 

within the Secure Terminal device, and using a key read Once the smart card has been "opened" by presentation of 

from the Retailer Card. If the Central Administration System the Master Secret Code, it can be set up to meet the 

is authentic, it will also have a record of this key, and will Customer's and Issuer's requirements. This involves creat- 

be able to encipher the challenge and send back the correct ing various data structures on the smart card, and writing 

response. 25 appropriate data to them, and to other locations on the smart 

5) Establishment of Session Keys card. All instructions on the manner in which the smart card 
Once both the Central Administration System and the is to be set up are sent from the Central Administration 

Retailer System have authenticated each other, they can System enciphered under the Central Administration Sys- 

mutually establish session keys for enciphering future data tern-Secure Terminal device session key 10. Similarly, all 

iralBc between them. This is done by one party sending the 30 data written to the smart card are sent from the Cenu-al 

other a random number. Both parties then combine these two Administration System enciphered under the Central 

numbers together (for example, by exclusive ORing them) Administration System-Secure Terminal device session key 

and encipher the result, using a key known only to them, to 10. 

produce a new number— the Session Key. Future data traffic 1 1) Entry of Customer Secret Code 

can then be enciphered using this session key. Whenever the 35 At this point, the Customer may be required to enter the 

session is terminated, and a new one started, new random Secret Code he will subsequently use to protect access to his 

numbers are used, resulting in a new session key. personal data held on the smart card. He is prompted on the 

Two session keys are required for securing conununica- Secure Terminal device display to enter his Customer Secret 

tionbetwccnthedifferentcomponentsof the system, one 10 Code, and does so using the Secure Terminal device's 

between the Secure Terminal device 7 and the Central 40 keypad. This ensures that nobody else, not even the Retailer, 

Administration System 5 and a second, optional, key 11 knows his Secret Code, The entered Secret Code is written 

between the Data Terminal device 6 and the Central Admin- to the smart card where it is securely stored to be used by the 

istration System 5. By using different session keys, tight smart card microprocessor to validate future presentations of 

security can be maintained because intermediate parties in the Customer Secret Code. 

an exchange of messages between two parties are not privy 45 With respect to FIG. 3, the issuer is first authenticated. In 

to the contents of the messages they are simply passing on. a step 52. at the issuer's secure computer, a cipher key 

6) Collection and Transmission of Customer Details associated with the serial number which had been previously 
The Retailer may now obtain from the Customer any received in step 32, is determined. The associated cipher key 

personal data required by the Central Administration System is retrieved in a step 52. The secure terminal device in a step 

before personalisation of a Customer smart card can pro- 50 54 uses a random number generator to generate a random 

ceed. This data may be entered into the Data Terminal number RN2. This random number is transmitted to the 

device, enciphered under the Data Terminal device-Central issuer's secure computer and enciphered in a step 56. It is 

Administration System session key 11 (to protect the con- also enciphered at the secure terminal device in a step. 58. 

fidentiality of the Customer data in transit over the link), and The issuer's secure computer transmits the enciphered result 

sent to the Cenu-al Administration System. 55 from the step 56 to the secure terminal device which 

7) Assessment of Customer Data compares in a step 60 that received enciphered result to the 
If appropriate, the Cenu^ Administration System now locally generated enciphered result, from the step 58. If there 

checks the Customer data (for example, runs a credit check), is no match, the attempt at authentication of the issuer is 

and determines whether or not personalisation of a Customer rejected in a step 62. In the event in a step 60 the two 

smart card may proceed. The decision is communicated to 60 enciphered codes match, in a step 64. the terminal authcn- 

the Retailer via the Data Terminal device. ticates the issuer. Once the issuer's secure computer has 

Personalisation of Customer smart card been authendcated at the secure terminal device, a session 

8) Selection of Customer smart card key can be established. A random number generator 70, at 
If the Central Administration System allows personalisa- the issuer's secure computer, generates a random number 

tion to proceed, the Retailer removes his Retailer Card from 65 RN3 and transmits same to the secure terminal device. Using 

the Secure Terminal device, selects a smart card from stock, a common key 72 associated with the retailer smart card CI 

and inserts it in the Secure Terminal device. The identity of present at the issuer's secure computer, the common key and 
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the random number RN3 along with another random num- 
ber, RN4 received from the secure terminal device, gener- 
ated in a step 78, are enciphered to produce a session key. 
Similarly, ai the secure tcnninal device in a step 76, the 
locally generated random number RN4 along with the 5 
received random number RN3 and the common key from the 
retailer smart card CI are enciphered in the step 76 to 
produce the session key at the secure terminal device. As is 
apparent from FIG. 3, a session key is required at the secure 
terminal device as well as to the issuer's secure computer. 
Information in steps 80, 82 can be transmitted between the 
customer's smart card, C2 and the issuer's secure computer 
after enciphering and deciphering using the session key. This 
is a bidirectional data transmission. 
Session Termination 

12) Customer Smart Card Handover 

The Customer may now remove his smart card from the 
Secure Terminal device and begin to use it. 

13) Termination of Communications Session 

The communications session with the Central Adminis- 
tration System is now lerminaied, which involves erasure of 
all session keys that were being used. 

14) Breaking of Communications Link 

The communications link with the CenUral Administration 
System may now be broken, or left open for use in the 
personalisation of other smart cards. 
Modification of Data on Customer smart cards 

There may be a need to modify some of the secure data 
on the Customer's smart card, at some stage after person- 
alisation. This can be accomplished by using exactly the 
same method, but varying the data that is written to the 
Customer smart card during the "Smart Card Set Up" step. 

With respect of FIG. 4, the secure terminal device STE7 
includes a tamper-resistant programmable device 90 which 
in turn receives information from a key pad 92, displays 
information on a display 94 and is coupled to a smart card 
read/writer 96. It communicates with a data terminal device 
DTE6 via a serial communications liok. 
An Example of Practical Implementation 

To take a specific example, the GSM digital mobile 
telephone network relies upon smart cards called Subscriber 
Identity Modules (SIMs), inserted in mobile telephone hand- 
sets to authenticate users as valid subscribers to the network. 
It also subsequently uses the Subscriber Identity Module to 
generate a different session key for each phone call made. 
This session key is used to encipher all data, such as voice 
data, transmitted from, and to, that mobile telephone during 
that call. In order to operate, therefore, each Subscriber 
Identity Module must be individually initialised to contain 
unique, identifying information and cryptographic keys 
prior to issue to a subscriber. 

Each Retailer is provided with the following: 

a Personal Computer (Data Terminal device); 

a secure, tamper-resistant PIN pad (Secure Terminal 
device), which incorporates a smart card reader; 55 

a Retailer smart card, already personalised by the Issuer 
and set up to contain: 

a Retailer Secret Code known only to the Retailer; 
cipher keys known only to the Issuer, in a file protected 

by an Issuer Secret Code from general access; 60 
a stock of unpersonalised blank Subscriber Identity 
Modules, that are protected from general access by a 
Manufacturing Secret Code. 
When a prospective new Subscriber to the network 
approaches the Retailer to open a subscription, the Retailer 65 
establishes a conamunications link with the Central Admin- 
istration System, using his Retailer smart card to authenti- 


25 


30 


35 


45 


50 


cate himself, and to authenticate the Central Administration 
System, and to establish session keys between the Secure 
Terminal device and Central Administration System, and 
between the Data Terminal device and (Central Administra- 
tion System. 

The Retailer then enters the new Subscriber's pereonal, 
and financial details into the Data Terminal device, where 
they are enciphered using the Central Administration Sys- 
tem-Data Terminal device session key and sent to the 
Central Administration System. In the Central Administra- 
tion System, the details are deciphered and used to run a 
credit check on the new Subscriber. If this is successful, the 
Retailer is notified, by means of an enciphered message sent 
from the Central Administration System to the Data Termi- 
nal device, that personalisation can proceed. 

The Retailer selects a Subscriber Identity Module from 
his stock, depending on Subscriber preference, and the type 
of mobile telephone the Subscriber will use. He inserts the 
Subscriber Identity Module in the Secure Terminal device 
and the personalisation data is sent from the Central Admin- 
istration System, enciphered under die Central Administra- 
tion System-Secure Terminal device session key. This data 
is deciphered in the Secure Terminal device before being 
written to the Subscriber Identity Module. This data includes 
instructions on the directory and file strucmres to be set up 
in the Subscriber Identity Module, as well as the information 
that is to be written to certain of these files, and to other 
locations in the Subscriber Identity Module. Data of par- 
ticular note that is written to the Subscriber Identity Module 
at this time is: 

the Subscriber's unique International Mobile Subscriber 

Identification (IMSI) number; 
the authentication key (Ki); 

the Subscriber Identity Module Service Table, which defines 
which of the available network services the Subscriber 
has actually accepted; 
the PLMN Selector, which sets up an initial order of 
preference for the selection of network, when the Sub- 
scriber is out of range of his home network. 
Once the Subscriber Identity Module has been set up, the 
Subscriber may enter his PIN Code (which will be his 
personal Secret Code protecting access to the Subscriber 
Identity Module) into the Secure Terminal device, which 
writes it to the Subscriber Identity Module. He may also 
enter his PIN unblocking key which is also written to the 
Subscriber Identity Module for use in the event the user 
forgets his PIN code. 

The telephone number of the Subscriber is then commu- 
nicated, enciphered under the Central Administration Sys- 
tem-Data Terminal device session key. from the Central 
Administration System to the Data Terminal device. The 
Retailer informs the Subscriber of the number, prints out a 
record of the entire transaction, and hands the new Sub- 
scriber his Subscriber Identity Module. The Subscriber is 
then in a position to use the network. 

At this point all communications sessions are terminated 
by the erasure of the session keys and the communications 
link may be broken. 

Since all information written to the Subscriber Identity 
Module originated from the Cenu-al Administration System, 
the Central Administration System holds a complete record 
of what is stored on the Subscriber Identity Module, as well 
as personal, financial and other Subscriber information. Ii is 
therefore able to route calls to the Subscriber, allocate 
charges correctly as they arc incurred, and issue bills. 
We claim: 

1. A method for securely writing confidential data from 
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issuer* s secure computer to a cusiomer smart card presented 
to a secure terminal device with smart card reader/writer 
connected to a retailer's data terminal device at a remote 
location, including the steps of: 

(a) establishing a communications link between the data 5 
terminal device and the secure computer; 

(b) authenticating the retailer to the issuer by: 

(i) presenting a retailer smart card to the secure termi- 
nal device reader/writer and establishing access to 
information stored in the smart card by entering a lO 
retailer secret code into the secure terminal device to 
unlock the retailer smart card 

(ii) reading data from the unlocked retailer smart card 
and sending only information pertaining to the iden- 
tity of the retailer smart card to the secure computer; 15 

(iii) generating and sending from the secure computer 
a fint random number to the secure terminal device; 

(iv) enciphering the first random number at the secure 
terminal device using a cipher key read from the 
unlocked retailer smart card, the cipher key having a 20 
value unrelated to the retailer secret code, and send- 
ing the enciphered first random number back to the 
secure computer; 

(v) comparing the retailer smart card identification data 
with data stored in the secure computer to identify 25 
the retailer smart card, then retrieving a cipher key 
stored in the secure computer associated with the 
identification data and enciphering the first random 
number with the cipher key; and 

(vi) comparing the enciphered first random number 30 
received from the secure terminal device with the 
enciphered first random number generated in the 
secure computer to authenticate the retailer when the 
values of the enciphered first random numbers are 
identical; 35 

(c) establishing a mutual session key for enciphering data 
transfer between the secure terminal and the secure 
computer after authentication of the retailer to the 
issuer has been effected, the mutual session key being 
generated by using a common key stored in the secure 
computer and the retailer smart card; 

(d) retrieving the retailer smart card and subsequently 
presenting the customer smart card to the secure ter- 
minal device; 

45 

(e) enciphering at the secure computer, the confidential 
data to be written to the customer smart card using the 
mutual session key and sending the enciphered confi- 

. dential data to the secure terminal device; and 

(f) deciphering at the secure terminal device, the enci- 50 
phered confidential data using the mutual session key 
and writing the confidential data on to the customer 
smart card. 

2. A method according to claim 1 including, after step (b), 
the step of 55 

(g) authenticating the issuer to the retailer by performing 
an enciphered challenge-response including: 

(i) generating at the secure terminal device a second 
random number, sending the second random number 

to the secure computer, and enciphering the second 60 
random number using a cipher key read from the 
unlocked retailer smart card; 

(ii) using the identification data of the retailer smart 
card, for the purpose of retrieving the cipher key 
stored in the secure computer associated with the 65 
identification data, enciphering the second random 
number using the cipher key and sending: the enci- 
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phered second random number back to the secure 
terminal device; and 
(iii) comparing the enciphered second random number 
received from the secure computer with the enci- 
phered second random number generated in the 
secure terminal device to authenticate the issuer 
when the values of the enciphered second random 
numbers are identical. 

3. A method according to claim 1 or claim 2, wherein the 
session key is established by the secure computer generating 
and sending a first random number to the secure terminal 
device, the secure terminal device generating a second 
random number and sending the second random number to 
the secure computer, the secure computer and the secure 
terminal device each enciphering the combined product of 
the two random numbers using the common key stored in the 
secure computer and the retailer smart card to generate the 
session key. 

4. A method according to claim 1, wherein the confiden- 
tial data to be written on the customer smart card is an issuer 
secret code which enables locking and unlocking of the 
customer smart card, the issuer secret code being required to 
imlock the card to accept data. 

5. A method according to claim 4, wherein the data also 
comprises a directory and file structures and other consumer 
specific data. 

6. A method according to claim 1, wherein a second 
session key is established for enciphering traffic between the 
data terminal device and the issuer's secure computer in a 
maimer analogous to the establishment of the session key for 
enciphering traffic between the secure terminal device and 
the secure computer. 

7. A system for securely writing confidential data from an 
issuer to a customer smart card in a remote location com- 
prising: 

an issuer's secure computer containing data pertaining to 
the identification of a plurality of retailer smart cards 
and respective associated cipher keys; 

a retailer data terminal device at the remote location 
selectively in communication with the secure computer 
by means of a communications link; 

a secure terminal device at the remote locating including 
a smart card reader/writer, selectively in communica- 
tion with the secure computer via the data terminal 
device; 

a retailer smart card containing data required to authen- 
ticate the retailer to the issuer including a retailer secret 
code to enable unlocking of the smart card upon 
positive comparison, with a secret code inputted into 
the secure terminal device, data pertaining to the iden- 
tity of the smart card, a cipher key to encipher an 
authentication challenge generated by the secure com- 
puter and sent to the secure terminal device, and data 
required to establish a session key for enciphering 
iraiOBc between the secure terminal device and the 
secure computer including a common cipher key stored 
in the retailer smart card and the secure computer; and 

a cusiomer smart card able to accept the confidential data, 
when presented to the secure terminal device, sent from 
the computer to the secure data terminal after being 
deciphered using the session key. 

8. A secure terminal which can be coupled to a remote 
computer, and a data link, intended for use with first and 
second, different, authorization cards comprising: 

a programmed processor; 

an input device coupled to said processor, and 
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a card reader/write coupled to said processor wherein said 
processor includes means for reading a first indicium 
from a first card and a second indicium entered via said 
input device and for comparing same, said processor 
including means, responsive to said comparing for 5 
reading a third, identifying, indicium from said first 
card and for transmitting same to the remote computer 
and for receiving a random number response from the 
remote computer, associated with said identifying indi- 
. cium, and for reading a fourth, key indicium from the lO 
first card for combining said random numeric response 
with said key indicium thereby producing an enci- 
phered random numeric response sent to the remote 
computer for authentication, wherein said processor 
includes means for establishing a different transaction 
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enciphering key in response to said authentication and 
wherein said processor includes means for reading a 
second card and for authorizing transactions using said 
transaction key and an identifying indicium carried by 
said second card and not entered by said input device. 

9. A terminal as in claim 8 wherein said processor 
includes means for entering onto said second card a user 
specified identifying indicium different from said transac- 
tion enciphering key. 

10. A terminal as in claim 8 wherein said processor 
includes means for terminating communication with the 
remote computer and wherein said transaction enciphering 
key is erased in response to said termination. 

***** 
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JAVA COMPATIBLE OBJECT ORIENTED 
COMPONENT DATA STRUCTURE 

HELD OF THE INVENTION 

This invention relates generally to data structures, and 
more particularly to data structures that are fully compatible 
with the Java Virtual Machine. Even more particularly, the 
present invention relates to tools, incorporating these data 
structures, for designing software components, and con- 
structing software applications. 

BACKGROUND OF THE INVENTION 

The Java language is well known in the art, and a brief 
review suffices for the purposes of the present invention. 
Java is an effective object-oriented programming language 
that shares many syntactical characteristics of the C and C++ 
languages. The popularity of the language emanates from a 
number of features, two of the principal (and related) ones 
are first that the language is portable, and, second, it is 
architecturally neutral. For example, some of the standard- 
ized features that make Java portable are that: 
Java provides the same Application Programmer Interface 

(API) for all systems; 
Java uses the 16-bit Unicode character set that can be used 

to encode all the symbols of virtually all the world's 

languages; and 

Java supports numerical and operand evaluation standards 

found in most other programming languages. 

Architectural neutrality is ensured by standardization on 
the Java Virtual Machine (JVM). This is a critical and very 
attractive feature of Java. When Java source code is com- 
piled the usual output is an intermediate code called Java 
Byte Code UBC); this code is not directly executable. Since 
JBC is a platform independent standard, there is a need for 
a platform-specific interpreter or compiler to provide the 
binary code that actually executes on a specific machine. 

The above features of the JVM emanate from its stan- 
dardized formation of object classes that are platform inde- 
pendent and, via the platform specific interpreter, made 
compatible and operational with the particular systems. Two 
standards for such object classes have emerged as the most 
popular — the JavaBean and CORBA (Common Object 
Request Broker Architecture) objects. JavaBeans often are 
graphical controls used in (but not limited to) the construc- 
tion of a Graphical User Interface (GUI). CORBA objects 45 
are capable of bridging language, machine, environment and 
other such boundaries. Java is described in "The Java 
Language Specification," Sun Microsystems Inc., Java- 
Beans are described in the "Java Beans API specification," 
version 1.00, Sun Microsystems Inc., and CORBA is 
described in the "Object Management Architecture Guide," 
3rd edition, from the Object Management Group, Inc., all of 
which are incorporated herein by reference. 

The widespread adoption of Java and Java compatible 
software and systems has made it desirable to provide 
software tools for applications developers that are compat- 
ible with the installed systems. The development, deploy- 
ment and maintenance of large and complex software 
applications, such as linc-of-busincss and packaged 
applications, introduce particular problems that are not typi- 
cally encountered in small-scale projects. Large projects 
become increasingly diflScult, time consuming and error 
prone, and ineflBciencies and limitations of the technologies 
and derived software tools become more pronounced and 
noticeable. Consider the following examples: 
1 . A relatively minor programming change in a product, such 

as changing the data type returned from a Java method. 
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requires every derived class which implements the 
method and every other class which invokes the modified 
method to be manually updated to reflect the change. 
Other changes are potentially much more destructive; for 
example, changing the name of the method may cause a 
conflict if a method further down the inheritance tree has 
the same name. 

2. It is routine for large software applications to be custom- 
ized (e.g. for specific customers or sites). In prior art 
systems, customization renders large software applica- 
tions nearly impossible to maintain. For example, con- 
sider a base software application that has been installed 
for many dilTerent customers. Each of these customers 
will usually change parts of the base application to 
accommodate their specific needs. The changes are 
accomplished by making modifications to parts of the 
program, or in object oriented programming, by modify- 
ing the classes of objects in the application. If the appli- 
cation vendor subsequently modifies these classes, and 
the customer wishes to upgrade the application to incor- 
porate those modifications, then the customer must deter- 
mine what customizations were made to the original 
classes and similarly customize the updated classes, 
(Alternatively, if the vendor's modifications are minor, it 
may be possible to isolate those changes and apply them 
to the older but customized version of the classes.) In a 
large customized application, this work is substantial 
enough that many customers continue to use out-of-date 
versions indefinitely. The effort that is required to upgrade 
a customized application is often larger than the original 
customization effort. Compounding the cost of upgrading 
is the potential for introducing new problems into a 
software application that is ab^eady in use. 

3, Localization is an additional requirement for many soft- 
ware applications and involves tailoring a software appli- 
cation to the language, input methods, and standards of a 
specific locale. This may include supporting different 
units of measurement and financial currencies, fulfilling 
legal requirements, and displaying dates, times, and cur- 
rencies in the expected formats. ITiese changes to an 
application provide challenges similar to those resulting 
from application customization; however, localization 
multiplies, rather than simply adding to, the number of 
potential application configurations, since a localized 
application can be customized or vice versa. 

With respect to this invention, the following four imple- 
mented concepts are important. The four are: Identity, 
behavior, state and containment which are defined and 
discussed below and are well known terms of art: 
Identity is used to exactly specify (to name) a class of 

objects, for example "button;" 
Behavior consists of the operations that a class of objects can 
perform, for example how a "button" reacts when pressed; 
State describes the current attributes of an object, for 

example the text di.splayed on a "button;" and 
Containment refers to a relationship between multiple 
objects where one object is contained within another, for 
example, the "button" could be contained within a "win- 
dow," 

In practice, well known in the art, the above items may 
typically be implemented on a computer display. A "win- 
dow" is typically a framed area, and a "button" appears as 
a smaller framed area within the window. The appearance is 
that of a physical window containing a physical button, 
where the button can be "pressed" or activated by "clicking" 
on it. 

Inheritance is a central feature of object-oriented pro- 
gramming in general and the Java language in specific. In 
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Java, heredity is substantially limited to the identity and particular "button/' then the "button" is positioned by the 

behavior of a class. The Java language lacks the notion of super class and then re-positioned by this "button" class, 

inheritance of state and containment. The slate of a Java Since more than two levels of inheritance are common, 

object is typically held by class variables, which the Java the "button" could literally jump around the screen while 

language calls "fields." The value of a field can be specified 5 it is being created. Although humorous as a visual 

only in the class that declares the field. Java programs example, the results would be less funny in a financial 

commonly use containment of objects, but not inheritance application. 

via the containment. Similar problems exist with containment. Generally, in 

Object-oriented programs built using the Java language the prior art, contained objects are not themselves classes 

are thus hmited by the lack of support for inheritance of state 10 and therefore do not have a class identity, an inherited stale, 

and containment as illustrated below. customized behavior, or recursively containment elements 

Mostof the technical terms used herein are defined by Dr. capable of these same features. Furthermore, in order to 

Grady Booch in his book, "Object-Oriented Analysis and support the inheritance of state, behavior, and containment 

Design," 2ed, published by The Benjamin/Cum mi ngs Pub- of all classes, it is essential that, when a containing class is 

lishing Co., Inc. in 1994, which book is incorporated herein is inherited, that the contained classes (and so on) be inherited 

by reference. as well. Since Java does not support containment, it obvi- 

lUustrating the inheritance issues with state and continu- ously does not provide inheritance of contained objects, 

ing with the "button" example, it is expected a "button" FIGS. 1 A and IB illustrate general prior art principles that 

would include its display position as part of its state. This are characteristic of Java inheritance. Several phrases exist 

implies that the "button" class, or a class that it inherits from, 20 that describe inheritance: if a descendant class "D" inherits 

declares position as part of its state. The act of positioning from an ancestor class "C," then it is said that "D is a C," that 

a "button" on a 'Vindow" defines the position portion of the "D extends C," that "D inherits from C," that "D derives 

state of the "button." Using this example, the limitations of from C," and that "C is a super class of D." FIG. lA shows 

prior art systems become evident: a simple class inheritance hierarchy which exists in Java: a 

1. If the aforementioned "button" on the "window" is itself 25 Button 2 "is a" 4 Component 6, which "is a" 8 Object 10. 
a class (which is to say that this particular "button" on this Furthermore, a Button 2 "is a" 4 and 8 Object 10, but this 
particular "window** has its own class identity), it cannot relationship is qualified as indirect, for example "Button 
define its position, since the position was declared in the indirectly inherits from Object" or simply "Button is a 
"button" super class from which this particular "button" descendent of Object." (For reference, the fully qualified 
inherits. 30 Java classes shown in FIG. lA are java.lang.Object 10, 

2. If the aforementioned "button" on the "window" is simply java.awt. Component 6, and java.awi.Buiton 2.) 

an instance of a generic "button" class (as in the most FIG. IB shows a larger class inheritance hierarchy that 

common prior art systems), then inheritance does not exists in Java, incorporating the hierarchy from FIG. 1 A. In 

apply, since this "button" is not in and of itself a class, and this diagram, as in FIG. lA, Component 14 "is a" Object 12, 

therefore does not inherit. 35 and Button 16 "is a" Component 14. Additionally, File 24 "is 

In the two examples above, prior art systems represent a" Object 12, Checkbox 18 "is a" Component 14, Container 

slate by constructing behavior. In other words, slate is 20 "is a" Component 14, and Window 22 "is a" Container 

implemented by producing Java language instructions that 20. The hierarchy is not limited in depth, and at any depth 

modify the object instance after it is instantiated; therefore: there can exist any number of classes. The design of the 

1. The state must also be induced from the behavior. 40 inheritance system mandates that each fully qualified class 

2. As part of the program source code, these instructions are name be unique and that all classes inherit directly or 
a source of entropy, making the program more error indirectly from Object 12. (For reference, the fully qualified 
prone, more difficult to maintain, and less capable of Java classes shown in FIG. IB are java.lang.Object 12, 
change. java.awi.Component 14, java.awi.Buiton 16, java.aw- 

3. The slate is not inherited. 45 I. Checkbox 18, java. a wt. Container 20, java. awl. Window 22, 
Continuing with this example, to appreciate the problem and java.io.File 24.) 

with inheritance, consider that the resulting state of this In contrast to the "is a" of FIGS. 1 A and IB, FIGS. 2A and 

particular "button" is the culmination of its inherited slate 2B pertain to containment, FIG. 2A illustrates a common use 

plus the changes to that stale which were made on this of containment, which is the containment of graphical 

particular "button" itself. There are two main ways which 50 objects. (The contained graphical objects are typically 

prior art systems have implemented this: referred to as "controls" or "components." The containing 

1. 'ITiis particular "button" would contain the instructions graphical object is often a "window," "form," "pane," "site," 
required to fully a)nfigure its slate as designed. This or just "container.") Although the Java implementations of 
approach fails to provide inheritance because changes to containment in the prior art vary widely, the concept of a 
classes from which this particular "button" derives would 5S container/containee relationship is extensively used for con- 
not be reflected in the instructions that configure the state structing complex objects, such as the object in FIG. 2A, In 
of this "button." this figure, the Message 26 contains Text 28 and OK 30 and 

2, This particular "button" would first execute the state Cancel 32 buttons. 

configuration instructions of its super class (the class FIG. 2B extends the example slightly from FIG. 2A by 

which it inherits from) and would then configure only the 60 adding recursive, or "nested," containment. Again, contain- 

portion of its state that differs from the state of its super ment is a hierarchy in which a container can contain objects 

class. This approach is limited because of its recursive that are themselves containers. In FIG. 2B, Choices 38 is 

nature (i.e. the super class itself may have a super class); contained by Message 34 and Choices 38 in turn contains 

each class must redo the state configuration of its super Shutdown 40, Restart 42, and Logoff 44. The expected 

class that differs from its own. As an example, consider 65 visual representation of Choices 38 and the graphical con- 

the position portion of the "button" stale. If the position trols that it contains would be a group of items, of which one 

of the super class is different from the position of this and only one can be selected. 
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It is an object of the present invention to provide a data 
structure that fully describes the identity, state, behavior, and 
containment information related to the design of a software 
component. A related object is that software components 
contained therein be able to utilize the same data structure (a 5 
nested instance thereof) to describe their identity, state, 
behavior, and containment information. 

It is another object of the present invention that the data 
structure can support the feature of inheritance with respect 
to the identity, state, behavior, and containment information. 10 
A related object is that software component information 
contained therein is inherited when the containing software 
component information is inherited; in other words, the 
inheritance applies to the entire containment hierarchy. 

It is another object of the present invention that the data 15 
structure can be implemented for and can be fully compat- 
ible with the JVM, allowing use at any and all particular 
installations. 

It is yet another object of the present invention that the 
data structure contains sufficient and unambiguous informa- 20 
tion in order to create Java classes from that information. A 
related object is that the resulting classes be Java software 
components capable of being assembled into or used in 
software applications and tools. 

Still another object of the present invention is that the data 25 
structure enables the computing system to do the bulk of the 
work when updates or other changes are made to an instance 
of the data structure. Most significantly, this applies to the 
feature of inheritance, in which a change to the design of a 
software component impacts those software components 30 
that inherit from it. Additionally, this applies to software 
customization and localization, which produce component 
modifications for particular customers and locales. A related 
object is to enable the computing system to automatically 
detect and fix conflicts and redundancies caused by such 35 
changes. 

Yet another object of the present invention is to provide a 
component data structure derived from a component data 
structure, wherein the derived component data structure 
elements can be reconstructed even if the base component 40 
data structure elements have been altered or removed. A 
related object of the present invention is to provide a "tag** 
associating the elements of a derived component data struc- 
ture to the corresponding elements in the base component 
data structure. 45 

Still another object of the present invention is to provide 
a delta component data structure wherein the elements of the 
delta component data structure are the differences between 
the elements of the base and the elements of the derived 
component data structures. 50 

SUMMARY OF THE INVENTION 

The above objects are met in computer systems operating 
in an object-oriented programming environment where the 
system or apparatus generates and maintains data structures 55 
for the design of components that are compatible with the 
Java Virtual Machine. 

The data structures provide means for defining the 
Identity, State, Behavior and Containment of the compo- 
nents. The identity provides the super component from 60 
which the component inherits, and the name of the compo- 
nent itself. The state provides the declared properties of the 
component and any values for those properties. The behav- 
ior provides the declared methods of the component and any 
implementations for those methods. The containment 65 
declares the types of components that can be contained and 
includes the contained components themselves; the con- 
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tained components are defined by nested versions of the 
inventive data structure. 

The data structure finds particular advantage for providing 
software tools for Java compatible systems, and especially 
for application developers, systems integrators, and infor- 
mation services providers. Moreover, tools for installing and 
controlling revisions and modifications are more easily and 
accurately accommodated with the present inventive data 
structures since there is a reduction in the manual operations 
to effect changes. 

Another advantage of the present invention, in a preferred 
embodiment, is that the data structure for one component 
that is derived from another may be held as the set of 
differences, a "delta," between the two data structures, rather 
than as a complete data structure. In this manner, inheritance 
is facilitated since the complete data structure for the derived 
component can be constructed by adding the delta data 
structure of the derived component to the complete data 
structure of the super component. In order to provide a 
robust implementation of the delta data structure, a "tag" is 
provided for each discrete unit of information within the 
component data structure; when changes are made to the 
super component, this tag correlates the information in the 
delta with the information in the super component. An 
additional advantage of the delta data structure is that it 
enables the customization and localization of componenLs: 
by storing component customization and localization infor- 
mation as deha data structures, changes to non-customized 
and non-localized component data structures are inherited 
by their customized and localized counterparts. A further 
advantage of the delta data structure is that it uses less 
memory and storage space. 

The inventive component data structures find further 
advantage by providing means for automatically, via the 
computer systems, incorporating changes among upgraded, 
customized and localized software applications, particularly 
in widely dispersed installations incorporating large soft- 
ware systems. Since changes made manually to a single 
component data structure are then automatically propagated 
to the impacted component data structures, the potential for 
human error is markedly reduced. 

Other objects, features and advantages will be apparent 
from the following detailed description of preferred embodi- 
ments thereof taken in conjunction with the accompanying 
drawings in which: 

BRIEF DESCRIPTION OF DRAWINGS 

FIGS. lA and IB are hierarchical diagrams of prior art 
inheritance; 

FIGS. 2A and 2B are hierarchical diagrams of prior art 
containment; 

FIG. 3 is a diagram of a simplified prior art Java system; 
FIG. 4 is a diagram of the innovative data structure; 
FIGS. 5A and 5B are diagrams of how component inher- 
itance is managed; and 

FIGS. 6A and 6B are diagrams of compiling the data 
structure for the JVM 

DETAILED DESCRIPTION OF PREFERRED 
EMBODIMENTS 

FIGS. 3A and 3B present a simplified typical Java system. 
In FIG. 3A, the Java compiler 52 transforms the input, Java 
source code 50, into a structure known as Java Byte Code 54 
(also referred to as the "Java.class file formal"). 'ITiis Java 
Byte Code 54 exLsLs as an interim step, which is then 
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provided as input 56 in FIG. 3B to an implementation of the In FIG. 4, state 68 declares properties 76 for which each 

Java Virtual Machine 58, resulting in a running application may have a value 84 defined. The declaration of a property 

60. It should be noted that in some installations, the raw Java 76 most notably includes a name of the property, which 

source code could be compiled to a platform-dependent uniquely identifies it within the component, and a data type, 

executable code structure, omitting the intermediate step of 5 There are further elements in the declaration of a property 

Java Byte Code. However, most applications follow the that reflect the particular standards and systems with which 

system as in FIGS. 2A and 2B, and those that compile the component must comply. For example, the JavaBean 

directly to executable code must still conform to the Java specification supports multiple values for an "indexed" 

Virtual Machine Specification, (Sun Microsystems Inc., property. The value 84 of a property is constrained by the 

copyright 1997). declaration of the property 76, for example by the data type. 

The import of FIGS. 3Aand3B is the realization that the In FIG. 4, behavior 70 declares methods 78 each with 

JVM is universal and platform independent. Th\s realization optional implementations 86 defined. The declaration of a 

provides a path where software components, applications, method 78 most notably includes the name and parameters 

and tools can be provided that are also universal and of the behavior, which uniquely identifies it within the 

platform independent. In order to achieve this, there exists component, and a return data type. There are further ele- 

the single requirement of compatibility with the JVM stan- raents in the declaration of a behavior that reflect the 

dard. Once Java Byte Code 56 is formed, all of the many particular standards and systems with which the component 

computing platforms that provide a JVM implementation 58 must comply. For example, the Java Language Specification 

will be able to run the code 60. Furthermore, according to provides a manner to declare "exceptions" that a method can 

the Java Virtual Machine Specification, the JVM is inde- "throw." Each implementation 86 provides the information 

pendent of the source from which the Java Byte Code is 20 necessary to be compiled into the instruction code of the 

formed: "the Java Virtual Machine does not assume that the particular systems. A preferred embodiment specifies the 

instructions it executes were generated from Java source "language" of implementation and an implementing 

code. [There] have been a number of efforts aimed at "script," where the language is used to determine the manner 

compiling other languages to the Java Virtual Machine ... of compiling the script. 

" (Java Virtual Machine Specification. Chapter 7, "Compil- 25 In FIG. 4, containment 72 declares component identity 

ing for the Java Virtual Machine"). constraints 80, which are the types of components that can 

Components are object classes in the broadest sense. The be contained within this component, and defines those 

term component refers both to the design of the object class components 88 that are contained. The ability to declare 

and the resulting output of the design. In the present containment 72 is based on the unique identity 66 that each 

invention, a preferred embodiment of a component is a data 30 component has. For example, if this component identity 

structure composed of identity, state, behavior, and constraint 80 limits containment to "Component. Control," 

containment, as displayed in FIG. 4. A preferred embodi- then only the component "Component.Control" and any 

ment of the resulting compiled output is Java Byte Code, as component inheriting directly or indirectly firom it may be 

illustrated in FIG. 6A. Additionally, the Java Byte Code contained within this component. 

adheres to the JavaBean standard. For these purposes, the 35 In FIG. 4, this same component data structure is used 

term "component" will be used hereinafter. recursively to hold the component information for a con- 

A preferred embodiment of the innovative component lained component 88. The only difference is that the con- 

data structure is shown in FIG. 4. The organization of the lained component *s unique identity is constructed from its 

data structure reflects the composition of a component as name and its containing component. For example, if a 

previously described: identity 66, stale 68, behavior 70, and 40 component inheriting from "Componenl.Control.Button" 

containment 72. Additionally, the data structure is concep- and named "OK" is contained within the component "Com- 

tually divided between declaration 62 and definition 64; ponent.Control.Container.Window.Message" (see FIG. 2A), 

declaration describes information about a trait of the com- then the unique identity of the OK button is "Component- 

ponenl and definition provides the actual "value." .Control, Container.Window.MessageSOK." In other words, 

In FIG. 4, identity 66 declares the "super component" 74 45 the containing component provides a namespace for the 

which is inherited from, and the identity or name 82 of the components it contains, (llie delimitation using a dollar sign 

inheriting component. There exists exactly one "root is a standard in Java for inner classes.) 

component," named "Component" that has no super com- In order to support component inheritance, features such 

ponent; all other components inherit directly or indirectly as containment that rely on inheritance, and the customiza- 

from the root component. (A single root in an inheritance 50 tion and localization of components, it is necessary that the 

hierarchy is well known in the art. For example, Java has a differences between two components be both determinable 

root class known as java.lang. Object.) A preferred embodi- and applicable. For these purposes, the terms Base, Derived, 

ment is such that the unique identity of a given component and Delta will be defined: 

is constructed from both its super component 74 and its Base — A data structure assumed to contain complete and 

name 82. This provides hierarchical organization by inher- 55 correct information; 

itance. Furthermore, all components inheriting from a given Derived — A data structure originally identical to the Base 

component share a namespace unique to the component data structure but which may have since changed; and 

from which Ihcy inherit. For example, a component with the Delta — The specific changes that must be applied to the 

name 82 "Control" and inheriting from the root component Base data structure in order to produce the Derived data 

("Component") would have a unique identity "Component- 60 structure. 

.Control." (The hierarchical delimitation using a period is a FIGS. 5A and 5B illustrate the above terms with respect 

standard in Java.) There are further elements in the decla- to the component data structure. In FIG. 5A, a component 

ration of a component's identity that reflect the particular delta "D^" 108 is extracted 106 from the derived component 

standards and systems with which the component must "D" 104 of the base component "B" 102. Thus, it must be 

comply. For example, the JavaBean specification defmes 65 possible to determine those difi!erences between "B" and 

how a component "dispatches" events to a JavaBean event "D" that are legal and store those differences in the form of 

listener interface. a delta. 
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By keeping the resulting component delta "D^" 108, b) means for associating said first with said second 

subsequent changes to the base component "B" are reflected component data structures, thereby allowing said first 

in the derived component "D" without losing those qualities component data structure to inherit from said second 

of "D" that made it different from "B." Tliis is illustrated in component data structure, 

FIG. 5B, in which the application ("resolve delta" 114) of 5 . ^^^^^ organizing said first and second component 

the component delta ;D 112 to the base component B ^^^^ structures in a hierarchy according to said 

110 results m the derived component D 116. . 

In a preferred embodiment, there are two categories of ' c • c 

differences ("dehas") between components; d) means for querying and modifying said first and second 

1. A component derivation represents the differences component data structures, 

between a component and its super component; the com- e) means for maintaining the integrity and organization of 

ponent derivation is therefore the result of an "inherit- said first and second component data structures 

ance" relationship between two components q ^^^^ containing said component data structures 

2. Acomponenlmodificationreprcsenlsthechangesmadeto inheriting of said contained component data 
a component as a resuh of versioning, customization or ^^^^^ ^^^^^^^ 

localization; the component modifications is therefore the -'^ 

result of comparing two different "versions" of the same g) in^ans for defining the identity, state, and behavior of 

component contained component data structures, and 

In a preferred embodiment, both the component deriva- h) means for the computer system to organize the con- 

tion and modification are themselves component data struc- tained component data structures in a hierarchy accord- 

tures; however, instead of carrying complete component 20 ing to containment. 

information, these data structures carry only the infonmalion 2. The object oriented component data structure as defined 

necessary to reconstruct the derived component from the daim 1 further comprising means for defining multiple 

base component. Additionally, each element (for example, hierarchical levels according to inheritance of data struc- 

property, method, and contained component) in a base tures. 

component and the corresponding element in a derived 25 3. ITie object oriented component data structure as defined 
and/or modified component includes a umquely identifying claim 1 wherein the first component data structure corn- 
datum (a "tag", which is an implementation of a unique prises means for defining an identity of said first component 
identifies, UID, a term well known in the art) which is used ^^^^^ structure, wherein said identity inherits from said 
to ensure the integrity and organizations for a correct reoon- second component data structure. 

struction of the derived component even if elements of the 30 4. xhe object oriented component data structure as defined 

base component have been added, removed, and renamed. claim 3 further comprising: 

When the delta elements (see above) are originally v c ^ a • * * e -a ™ * a^*^. 

- , , ^ r . , ^ y a) means for defining a state of said first component data 

extracted, the tag for the elements or the base component is ^ ^ , 

structure anO 

duplicated in the corresponding elements of the derived ' 

component thereby uniquely associating the base and 35 b) means for defining a behavior of said first component 

derived elements to each other. The tag for each particular ^^^^ structure, 

element remains constant for the life of that element. therein said slate and behavior of said first component data 

HG. 6A illustrates the manner in which the innovative structure are inherited from said second component data 

data structure is compiled into Java Byte Code, thus fulfill- structure. 

ing the single requirement of compatibility with the JVM 40 ^ "^'Jf ^ component data structure as defined 

standard iUustrated in FIG. 3B. It is therefore important to ^^^^^"^ f^^^^er comprising: 

ensure that the component data structure is constrained by a) means for containing third component data structures 

the JVM specification such that legal Java Byte Cbde will be within the second component data structure, and 

produced for the component data structure. As shown in b) means for containing fourth component data structures 

FIG. 6B, it is also possible that the component data structure 45 within the first component data structure, wherein said 

be compiled first into Java source code and then, as shown fourth component data structures inherit from the third 

in FIG. 3A, be compiled into Java Byte Code. component data structures. 

In a preferred embodiment, the component data structure 6. The object oriented component data structure as defined 
iswritteninJava, is compatible with the JVM, and compiles in claim 5 wherein identity comprises the name of the 
to produce legal JVM classes. The component data structure 50 component data structure, wherein said state comprises the 
must be such that it can be stored and, when stored, it can properties of the component data structure and the value of 
be loaded, that the computing systems accommodate the said properties, wherein said behavior comprises how the 
component, and that the component meets any applicable component data structure operates and the code necessary to 
standard. implement said operation, and wherein containment corn- 
It will now be apparent to those skilled in the art that other 55 prises the component data structures that are contained 
embodiments, improvements, details and uses can be made within the component data structure, 
consistent with the letter and spirit of the foregoing disclo- 7. The object oriented component data structure as defined 
sure and within the scope of this patent, which is limited in claim 6 wherein said data structure is substantially 
only by the following claims, construed in accordance with consistent with the Java Virtual Machine standard, and 
the patent law, including the doctrine of equivalents. 60 further comprising means for creating Java Virtual Machine 
What is claimed is: class file structures. 

1. An object-oriented component data structure of a Java 8. The object oriented component data structure as defined 

compatible type for defining components, for use in a in claim 6 wherein said data structure is substantially 

computer system providing enhance inheritance, compris- consistent with the JavaBean component model standard, 

ing: 65 and further comprising means for creating Java Virtual 

a) means for defining a first component data structure and Machine class file structures which are JavaBean compo- 

a second component data structure, nents. 


02/20/2004, EAST Version: 1.4.1 


6,115, 

11 

9. The object oriented component data structure for com- 
ponents as defined in claim 5 wherein said first data structure 
comprises: 

f) means for uniquely tagging each clement in said second 
data structure, s 

g) means for tagging each element in said first data 
structure, wherein said tagging relate the corresponding 
elements in the first and the second data structures, so 
that changes to elements in the second data structure 
can be related to the corresponding elements in the first ^° 
data structure. 

10. 1lie object oriented component data structure as 
defined in claim 5 wherein said first component data struc- 
ture comprises: 

means for determining the differences between said first 
and said second component data structure, and 

means for storing as a delta the information that is 
different between said first and said second component 
data structures. 20 

11. A method for defining object-oriented component data 
structures of Java compatible types for defining components, 
for use in a computer system, providing enhanced 
inheritance, comprising the steps of: 

a) defining a first component data structure and a second 25 
component data slruclure, 

b) associating said first with said second component data 
structures, thereby allowing said first component data 
structure to inherit from said second component data 
structure, 30 

c) organizing said first and second component data struc- 
tures in a hierarchy according to said inheritance, 

d) querying and modifying said first and second compo- 
nent data structures, 

e) maintaining and retaining the integrity and organization 
of said first and second component data structures in 
said hierarchy. 
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12 

f) containing component data structures and the inheriting 
of said contained component data structures to be 
recursive, 

g) defining the identity, state, and behavior of contained 
component data structures, and 

h) organizing the contained component data structures in 
a hierarchy according to containment using a computer 
system. 

12. The method as defined in claim 11 further comprising 
the step of defining multiple hierarchical levels according to 
inheritance of data structures. 

13. The method as defined in claim 12 wherein the step of 
defining a first component data structure comprises the step 
of: 

identifying said first component data structure, wherein 
said identity inherits from said second component data 
structure. 

14. The method as defined in claim 13 further comprising 
the steps of: 

defining a state of said first component data structure, and 
defining a behavior of said first component data structure, 
wherein said state and behavior of said first component 
data structure are inherited from said second compo- 
nent data structure. 

15. The method as defined in claims 14 further comprising 
the steps of: 

a) containing third component data structures within the 
second component data structure, and 

b) containing fourth component data structures within the 
first component data structure, wherein said fourth 
component data structures inherit from the third com- 
ponent data structures. 

***** 
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[57] ABSTRACT 

A smart card personalization system maintains a database 
containing card issuer data format templates, card 
applications, card operating system commands, and person- 
alization equipment specifications and provides a central- 
ized interface of inputs and outputs to a card issuing process 
which dynamically adjusts to changes in the issuing process 
to easily permit a card issuer to change data formats, card 
appHcalions, card operating systems and/or personalization 
equipment in a card issuing process. The system interfaces 
to any card issuer management system, manages the transfer 
of card holder data and card applications to the particular 
personalization equipment used, and maintains statistics for 
real-time and off-line inquiries to support critical manage- 
ment and reporting functions. Furthermore, the system 
works with a variety of security methodologies to prevent 
fraud. 
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SYSTEM AND APPARATUS FOR SMART control of a specific card operating system and to formal the 

CARD PERSONALIZATION data for the card to be compatible with a specific type of 

personalization equipment chosen to issue the card. The 

RELATED APPLICA'l'ION entire issuing system must be re-conflgurcd whenever any 
™. .... .-1 ,. , . ■ 5 one of these variables (issuer application, smart card/card 

msappbcai.on ,.a non-prov.s.on^ ^^^^^^ pereonalization equipmen.) is 

benefit under 35 U S C. § 119 e) of US Provis'onal Apph- changedfincreasmg the lime and cost incurred by the issuer 

cafon Scr. No. 60/015.743. filed Apr. 15. 1996. ^^^^ ^ ^^^^^^j^^ pe«onalized smart cards to its 

FIELD OF THE INVENTION customers. Additionally, many of the current issuing systems 

10 lack a viable means to provide dynamic feedback regarding 

The present invention is related to data storage devices the status of any particular batch of cards in the process to 

and in particular to producing portable programmed data the card issuer. 

carriers such as credit cards, debit cards, identification cards. Furthermore, the smart card issuing systems in use today 
and other transaction cards. utilize a proprietary approach developed by either the card 
manufacturer or the personalization equipment raanufac- 

BACKGROUND OF THE INVENTION Vli.e th.^, rl.jl^ti... ^.r^o 

turer. lo encourage sales or their respective cards or 

Increasing numbers of organizations which issue transac- equipment, each manufacturer develops a unique personal- 

tion cards to their users, customers, or employees require ization solution for a particular card apphcalion, and each 

cards tailored to meet the requirements of their particular solution is specific to a particular card issuer. These unique 

service or application. These organizations also want the solutions are intended to optimize performance of the cards 

cards to contain data about the card holder. Existing trans- or equipment and thus do not permit a more inclusive, 

action cards encode such data in a magnetic stripe on the generalized personalization process that accepts any card 

back of the card but the amount of data that can be held by operating system and/or work with any personalization 

a magnetic stripe is limited. A new type of transaction card equipment. 

embeds a microprocessor computer chip in the plastic of the As the demand for smart cards increases, a smart card 

card to greatly increase the card's data storage capacity. issuing system which permits the card issuers to use any type 

Additionally, sophisticated card applications specific to the of personalization equipment to handle multiple types of 

card issuer can execute in certain varieties of the chips, and smart cards, and their attendant operating systems, and to 

the chip may also contain a type of operating system. embed the issuers* specific card applications along with the 
Transaction cards with embedded chips are referred to in the ''^ required card holder data in any of the various types of smart 

industry as portable programmed data carriers, more com- cards is required, 
monly called "smart cards." The chip in a smart card is 

programmed with initialization and/or personalization data SUMMARY OF THE INVENTION 

at the same time as the surface of the card is being embossed . . 
A/ • t A 35 A smart card personalization system maintains a database 

^ containing card application data, issuer format template 

The mitialization data comprises three major types of ^^1^, card operating system data, and personalization equip- 

informalion: application data, security data, and printed ment data to permit a card issuer to dynamicaUy change card 

data. The application data is common to all cards for a given applications, card and card operaUng systems, and/or per- 

card application and includes application program code and ^ sonalization equipment in a card issuing process without the 

variables. The security data prevents fraudulent use of the necessity of modifying the card issuer's interface to the 

card and is usually provided in the form of "secure keys." issuing process 

Printed data, such as a logo, bar codes, and various types of rj^^ «^«-„«„i;,„t:„„ 

. ,. _ ° . , * _ J Ine smart card personauzation system issues portable 

numerical information, are placed on the surface of the card. „ , ^^.^o u., v.«™ 

c n r J . 1 i_ 1- J programmed data carriers, or smart cards, by first acquinng 

Some or all of he same data can also be embossed on the ^ ^f^^ ^^^^^^ ^ ^^^^ . .^^"^ a 

surface. Optical technology also can be employed to make personalization equipment identifier, an application program 

part or all of the surface of the card mto a storage medium .^^^^.^^^ identifiers, and personalization data for a card 

with data accessible by an appropriate optical reader. ^^^^^^ ^^^^ ^ ^^^^ .^^^^ management system. The identi- 

Smart cards are also programmed with mformaUon spe- fig^s permit the system to address data stored in a data 
cific to an individual card holder through a process called 50 structure, such as a database, and specify the particular data 
"personalization." The persona hzation information for a ^^^^^^ ^y the system for each card to be issued. Because 
smart card is similar to the personalization mformation g^ch card issuer formats its personalization data differently 
currently contained on non-smart cards, such as the card ^^^y ^ave multiple data formats, the smart card person- 
holder's name, account number, card expiration date, and a ali/ation system has a dalaba.se of data format templates that 
photograph. Because of its mcreased storage capacity, the 55 ^^^^^^^ interface with multiple card issuer management 
chip m a smart card can contain additional data beyond the systems. The system acquires the format template defining 
basic information on the standard transaction card including ^^e personalization data used by a particular card issuer from 
a graphical representation of the individual's signature, data ^ accord in the database identified by the data format 
definmg the types of service the card holder is entitled lo, identifier. The system uses the data formal template to 
and account limits for those services. translate the personalization data from the card issuer's 

The smart card issuing process must control and report on format into an internal format recognized by the components 

each personalized card and the results of the personalization of the system. The system uses the card operating system 

process. Extensive report and audit files thus must be identifier and application program identifier(s) to acquire 

maintained to support the card tracking requirements. programming control commands for an operating system 

Currently, a smart card issuing system must be tailored to 65 pre-loaded in a microprocessor chip embedded in the card, 

meet the requirements of a specific card application that will and application data, in the form of code and/or variables, 

be programmed on a specific type of smart card under the for an application program type or types from the database. 
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The system also acquires the equipment characteristic data types of data elements and uses "indices" or "identifiers" to 

for the personalization equipment to be used to issue the quickly access specific data. There are four main data 

smart card using the personalization equipment identifier. elements in the system: a data format element, a card 

Once the system has acquired all the data necessary to issue operating system clement, an application program clement, 

the smart card it transfers the programming control 5 and a personalization equipment clement, 

commands, the application code and variables, and the The data format element contains a template that defines 

translated personalization data to the personalization equip- the format of the personalization data used the card issuer, 

ment as specified by the equipment characteristic data. The data format element may be stored in a database 

Alternatively, no data format identifier is passed by the containing data format elements for various card issuer and 

card issuer because the data format template is derived from ^0 the information stored in the data format element is accessed 

data in the application data record or because the format of through the data format identifier. Alternatively, the data 

the personalization corresponds on a one-to-one basis with format element may be derived at the time the card is issued 

the internal format used by the system. ITie card issuer may from data in the application program element(s) so that the 

also substitute the data format template record for the data application program identifier(s) passed by the card issuer 

format identifier so the system does not need to reference its ^5 identify the data format. When the data format of the 

database of format records. personalization data corresponds exactly to the internal 

Another feature of the smart card personalization system format used by the sniart card personalizatioti system, the 
is its card management function. The smart card personal- data format template is logically implied which creates a 
ization system collects information regarding the card issu- virtual data format element for the issuing process, 
ing process and reports this information to the card issuer The card operating system element holds the program- 
management system. ming control commands that direct the card operating sys- 

Smart cards may include one or more "secure keys" that tems controlling a smart card chip and is accessed through 

are programmed into the chip to prevent fraudulent use of the card operating system identifier, 

the card. The appropriate secure key data is obtained by the The application program element(s) contains application 

smart card personalization system from secure key records data, such as program code and variables, required by the 

maintained by the card issuer, or another security source, applications associated with various card issuers; applica- 

and then transferred to the personalization equipment. The tion data is accessed through an application program 

security source also provides security functions that are used identifier(s). 

by the smart card personalization system to ensure the Operating parameters for various types of personalization 

inlegnty and secrecy ofdata during the transmission of data equipment used to issue smart cards are stored in the 

to and from the system and within the system during the personalization equipment element and accessed through a 

smart card personalization process. personalization equipment identifier corresponding to the 

The smart card management system performs the func- type of the personalization equipment to be used during an 

tions described above through a series of software modules 35 issuing run. 

executing on a computer or multiple computers. One module ^^^^-^ configurations of the smart card personalization 

is a card is^er management system interface which acquires ^y^^^^ ^^^^^ ^^^^ ^^t need the full flex- 

the data format identifier, the card operatmg system ibility of the system described above, 

identifier, the personalization equipment identifier, the appli- ^ , , ... . j, 

cation program idenliMs). and the personalization data for ^ ^he smar card personahzation system addresses the 

a card holder from the card issuer mknagement system. The ^ '^^ P"°^ f ".''^ P:°^"''"g ' ""'^'^l-'-ed inter ace 

, . * . • * .u *u J * 01 mputs and outputs to the smart card personalization 

card issuer management system interface then uses the data t.-i..j-j . -i, , 

format identifier To acquire the format template that defines ^^'^^ to dynamically accommodate 

1- «• J. J* 1 4 »u I- changes in the issuing process. The system interfaces to any 

the personalization data and translates the personalization . ° , i- r j, 

J . . , . . 1 J . r . A J issuer management system, manages the transfer of card 

dataintothecommon, internal data format. A card operating a*; u u j * j j i- f t 

. , ^ . , • • * 1 " holder data and card applications to the particular person- 
system interface module acquires the programming control ... . J J 1. • . f 1 . 
^ J f J . * -c J u alization equipment used, and collects Statistics for real-time 
commands for the card operating system type specined by j m- - • • • . 
the card operating system identifier. A card applicatioJ. ""'^ mquines to support critical management and 
interface module uses the application program idenlifier(s) ^P°"'"e fi!"^"o>«' TTj^ system maintams a database of 
to determine which type(s) of application program is to be ,0 "^"^ operatmg systems, card apphcalion 
placed on .he card and acquires the specified application '° P^S^*""*' """^ 'yP« °\ personahzat.on equ.pmen . n..s 
code and variables. A peis^nalization ^uipmenl interface database enables the system to handle any combmat.on or 
, , . ui f *u • r.u • . permutations of the data, thus improving cost and time to 
module is responsible for the acquisition of the equipment , . r . ,^ . . - r 

. . • J . r .L 1- • . . market lor the issuer. Hurthermore, the system interfaces 
characteristic data for the personalization equipment type ■ . . ^ j . • j i- . 
specified by the personali^^alion equipment identifier, and "^''^ ^^^^ ^^"»y methodologies to reduce fraud, 
further for transferring the programming control commands. BRIEF DESCRIPTION OF THE DRAWINGS 
the application code and variables, and the translated per- 
sonalization data to the personalization equipment in accor- FIG. lA is a block diagram representing a smart card 
dance with the requirements stipulated by the equipment issuing process that incorporates a smart card personaliza- 
characteristic data. tion system. 

The reporting and security functions are provided by a FIG. IB is a functional block diagram of input and output 

tracking/report module and by a secure key management connections for the smart card personalization system shown 

module. in FIG. LA. 

The smart card personalization system uses an underlying FIG. IC is a functional block diagram showing software 

data structure, such as a database, residing in a computer 65 modules and data structures which comprise one embodi- 

storage medium to organize the data necessary to issue the ment of the smart card personalization system shown in FIG, 

smart cards. The data structure comprises several different IB. 
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FIG. 2 is the functional block diagram of the embodiment 
of FIG. IC with the addition of a security module to manage 
keys used for smart cards. 

FIG. 3 is a functional block diagram of another embodi- 
ment of the smart card personalization system showing a 
minimal configuration to manage multiple types of cards and 
personalization equipment. 

FIG. 4 is the functional block diagram of the embodiment 
of FIG. 3 with the addition of a module to manage multiple 
card operating systems. 

FIG. 5 is the functional block diagram of the embodiment 
of FIG. 4 with the addition of the security module. 

FIG. 6 is the functional block diagram of the embodiment 
of FIG. 3 with the addition of a module to manage multiple 
card applications. 

FIG, 7 is the functional block diagram of the embodiment 
of FIG. 6 with the addition of the security module. 

FIGS. 8A, B represent a high level flow chart for com- 
puter software which implements the functions of the smart 
card personalization system. 

FIG. 9 is a functional block diagram of an alternate 
embodiment of the smart card personalization system using 
software modules and data records. 

FIGS. lOA, B represent a high level flow chart for 
computer software which implements the functions of the 
embodiment of the smart card personalization system shown 
in BG. 9. 

FIG. 11 is a data field chart for a card framework template 
record used by the embodiment of the smart card personal- 
ization system shown in FIG. 9. 

FIG. 12 is a data field chart for a data format template 
record used by the embodiment of the smart card personal- 
ization system shown in FIG. 9. 

FIG. 13 is a data field chart for a card application data 
record used by the embodiment of the smart card personal- 
ization system shown in FIG. 9. 

FIGS. 14, 14A, 14B represent a report format showing 
sample items tracked by the smart card personalization 
system. 

DESCRIPTION OF TIIE EMBODIMENTS 

In the following detailed description of the embodiments, 
reference is made to the accompanying drawings which 
form a part hereof, and in which is shown by way of 
illustration specific embodiments in which the invention 
may be practiced, 'Iliese embodiments are described in 
sufiicient detail to enable those skilled in the art to practice 
the invention, and it is to be understood that other embodi- 
ments may be utilized and that structural, logical and elec- 
trical changes may be made without departing from the spirit 
and scope of the present inventions. The following detailed 
description is, therefore, not to be taken in a Umiting sense, 
and the scope of the present inventions is defined only by the 
appended claims. 

The leading digit(s) of the reference numbers in the 
Figures usually correspond to the figure number, with the 
exception that identical components which appear in mul- 
tiple figures are identified by the same reference numbers. 
Issuing Smart Cards 

Standard transaction cards such as regular credit cards are 
familiar to most people. A transaction card usually has 
information about the card holder, such as name and account 
number, printed and/or embossed on the surface of the card. 
Transaction cards frequently contain a magnetic stripe 
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which is encoded with card holder data as well. The process 
of printing/embossing/encoding the card holder data on each 
transaction card is known as "personalization." Each trans- 
action card also undergoes a process known as "initializa- 

5 tion" in which certain types of information common to all 
cards in a batch, such as an issuer identifier and batch 
number, are placed on the card. 

A smart card differs from a standard transaction card in 
that a computer microprocessor chip is embedded in the 

10 plastic of the card to greatly increase the card*s data storage 
capacity. In some varieties of smart cards, the card manu- 
facturer pre-loads the chip with one of several possible card 
operating systems and the operating system controls the 
programming of the chip during the personalization process. 

IS Additionally, sophisticated card applications specific to the 
card issuer may execute in certain varieties of the chips. 

The initialization data for a smart card comprises three 
major types of information: application data, security data, 
and printed data. The application data is common to all cards 

20 for a given card application and includes application pro- 
gram code and variables that are programmed into the chip. 
The security data, usually provided as secure keys or secu- 
rity functions, validates the data on the card and prevents 
fraudulent use of the card. Printed data, such as a logo, bar 

25 codes, and various types of numerical information, are 
printed on the surface of the card. Some or afl of the same 
data may also be embossed on the surface. Optical technol- 
ogy also may be employed to make part of the surface of the 
smart card into a storage medium with data accessible by an 

30 appropriate optical reader. 

The personalization information for a smart card is similar 
to the personalization information currently contained on 
non-smart cards, such as the card holder's name, account 
number, card expiration date, and a photograph. Because of 

35 its increased storage capacity, the chip in a smart card may 
contain additional data beyond the basic information on the 
standard transaction card including a graphical representa- 
tion of the individual's signature, data defining the types of 
service the card holder is entitled to, and account limits for 

40 those services. 

Smart Card Personalization System 

FIG. lA shows components of a smart card issuing 
process that incorporates an embodiment of the smart card 
personalization system of the present invention. The smart 

45 card pcrsonaUzation system 100 receives data from a card 
issuer management system 150 (typically proprietary to the 
card issuer), translates the data into a data stream, and 
outputs the data stream to personalization equipment 130 
which personalizes the smart cards 160. The card issuer 

50 management system 150 manages the card holder data and 
determines the type of card to issue, the card applications to 
embed in the card, and what personalization equipment to 
use to issue the card for a particular card holder. The card 
issuer management system is frequently a wmputer program 

55 as illustrated in FIG. lA, but the smart card personalization 
system 100 is capable of receiving data from alternate 
inputs, such as a person inputting the data from a telephone 
keypad. 

The smart card personalization system 100 is illustrated in 
60 FIG. lA as a software program executing in a computer. As 
described below, the smart card personalization system 100 
accesses database records which define various types of 
cards and card operating systems, card applications, and 
personalization equipment. The logical functions of the 
65 software and the database may be distributed among com- 
puters in a client/server network or centralized into a single 
processor. The functions may also be distributed across 
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processors connected through standard local area networks, key manager 111 and secure key database 128, provides 
wide area networks, dedicated phone lines or other commu- security functions that work in conjunction with the card 
nication means used to loosely couple processors. The issuer management system 150 and the smart card person- 
software program executes under an operating system such alization system 100. FIG. IB also illustrates an alternate 
as Unix, Windows 95€), or Windows NT(D, and on industry- s embodiment of the smart card personalization system 100 
standard workstation and/or personal computer hardware. which supports a card issuer that has add-on smart card 
The system 100 controls card printers, embossing devices, interface devices. The system 100 directs a portion of the 
and integrated or add-on smart card interface devices col- personalization information to the older personalization 
lectively represented in FIG. lA as personalization system equipment 130 and the remainder of the data to a post- 
130. Personalization equipment 130 also represents such 10 processor 132 in the smart card interface device 132 which 
devices as large volume card printer/embossers, small vol- programs the chip. These functions are explained in detail 
ume card printer/embossers, automatic teller machiners below, 

(ATMs), point of sale terminals, unattended kiosks, personal The embodiments of the software program for the smart 

computers, network computers, and on-line telecommuni- card personalization system 100 shown in the following 

cation devices. Because of their investment in existing 35 Figures function as combinations of code modules with each 

non-smart card personalization equipment, many card issu- module executing a specific part of the issuing process. In 

ers do not purchase entirely new smart card personalization these embodiments, the modules are coupled through 

equipment but instead augment their existing personaliza- defined input and output program calls, and are also coupled 

tion equipment with a smart card interface device which to the data structures through standard data query commands 

programs the chip in the card while the older device per- 20 that provide access to the data stored in the data structures, 

forms the printing and embossing functions. In such a The communication protocols between the modules, and 

configuration, the computer system executing the smart card between the modules and the data structures vary depending 

personalization system 100, or "host," may be physically on the language in which the modules are written and upon 

connected to both devices or to only one of the devices. In the underlying data management system employed to sup- 

the latter case, the host controls the directly-connected 25 port the database. 

device and has a logical connection to the other. The FIG. IC is a more detailed functional block diagram of the 

physical connection between the devices and the host varies smart card personalization system 100 of FIG. 1 B without 

according to the manufacturer and model of the device. the external security functions. FIG. IC shows the internal 

Common industry standard connections include serial connections between software modules and database records 

RS232, SCSI (Small Computer System Interface), Ethernet, 30 that enable the smart card personalization system 100 to 

and serial TTL (Transistor-Transistor Logic). In addition, combine multiple types of issuer data formats, card operat- 

some devices require a proprietary bus connection. ing systems, card applications and personaUzation equip- 

The connections between the smart card personalization ment when issuing smart cards, 

system 100 and the card management system 150 and the Th^ smart card personalization system 100 provides a 

devices 130 may also be implemented through standard 35 customized card issuer management interface 101 to a card 

local area networks, wide area networks, dedicated phone issuer management system 150. In this embodiment, the 

lines, or other remote communication infrastructure used to card issuer management system 150 passes personalization 

transfer data. The use of such remote connections when data from a card holder database 152 to the system 100. Each 

personalizing smart cards is described in U.S. Pat. No. software module within system 100 expects the personal- 

5,524,857 issued on Jul. 9, 1996, to Laing, et al. Alternate 40 ization data to be passed to it in a particular, intemal formal, 

connections will be apparent to those skilled in the art and Because the personalization data is in an external format 

are within the scope of the invention. defined by the card issuer that often differs from the intemal 

FIG. IB is a block diagram of one embodiment of the format(s) expected by the software modules, the personal- 
smart card personalization system illustrating the logical ization data is translated by the system 100 into the intemal 
connections between the smart card personalization system 45 format(s) using the data format template. The system 100 
100 and functions employed by a card issuing organization may acquire the data format template through a data format 
to issue smart cards. Card holder data maintained by the card identifier passed by the card issuer that the system 100 uses 
issuing organization contains information about each indi- to acquire an optional data format template record 120 
vidual card holder, such as name, account number, card (shown in phantom in FIG. IC) as illustrated by an optional 
expiration date, and applicable services. Various ways of 50 connection between the record 120 and the card issuer 
inputting the card holder data into the card issuer manage- management system interface 101. Alternatively the card 
ment system 150 are shown in phantom as card holder data issuer passes the data format template record to the system 
152 in FIG. IB, The card issuer management .system 150 100 instead of the data formal identifier. In another 
may receive the card holder data on computer media, such embodiment, the data format template may be derived from 
as magnetic tape, floppy disk, or CD ROM. Alternatively, 55 the data in the card application record 124 that is specified 
the card holder data 152 may be input through an on-line by an application program identifier passed by the issuer as 
connection such as a general switched telephone network, a illustrated by an optional connection between the card 
packet -switched network, i.e., the Internet, a dedicated line, application database 124 and the card issuer management 
or a cable/satellite television signal. Additional ways in system interface 101. 

which the card holder data 152 may be input to the system 60 In a further alternate embodiment of FIG. IC, security 

150 will be apparent to those skilled in the art, functions are provided internal to the smart card personal- 

In addition to the card issuer management system 150, the ization system 100, by passing security functions into the 

card issuer typically has an existing reporting capability 154 system as part of the card application record, 

with which the smart card personalization system 100 inter- A further alternate embodiment in which the personaliza- 

faces so that the card issuer can review statistical informa- 65 tion data format matches the internal format is also shown in 

tion maintained by the system 100. An external security FIG. IC. Because no translation between the external and 

source, also provided by the card i.ssuer and shown as secure internal formats is necessary in this embodiment, no data 
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format template is needed so the data format record 120 and 
the connections between the card issuer management system 
interface 101 and the data format record 120 and the card 
application database 124 arc not present. The data format 
record may 120 be composed of a plurality of tables which 
instruct the system 100 as to the proper parsing of the 
personalization data or a simple list that indicates the order 
in which the fields of the card holder data record appear as 
will be apparent to those skilled in the art. The various 
alternate procedures for determining the format of the per- 
sonalization data described above are implicit in all the 
embodiments of the smart card personalization system 100 
described herein. 

Using a card identifier provided by the card issuer man- 
agement system 150, a card operating system interface 
module 103 retrieves programming control commands spe- 
cific to the card operating system 122 for the microprocessor 
chip that Ls embedded in the type of card being issued. The 
programming control commands direct the encoding of the 
chip with the personalization data and the card application(s) 
chosen by the card issuer. 

Each card application comprises program code and vari- 
able data that is stored in the database as application data 
124 and is identified by an application program identifier, 
'ilie card issuer management system 150 passes one or more 
program application identifiers to the system 100 which are 
used by a card application interface module 105 to acquire 
the corresponding application data 124. 

The personalization equipment that the card issuer plans 
to use to issue the batch of cards is defined by a personal- 
ization equipment identifier. A personalization equipment 
interface module 107 acquires eqtiipment characteristic data 
126 specific to the type of personalization equipment 130 
corresponding to the personalization equipment identifier. 
The personalization equipment interface 107 also acquires 
the programming control commands, the application code 
and variables, and the translated personalization data, and 
transfers all of this data to the personalization equipment 
130 as specified by the equipment characteristic data 126 to 
issue the smart card. 

An alternate embodiment of the system 100 supports a 
card issuer that has augmented their existing personalization 
equipment with a smart card programming device by having 
the personalization equipment interface 107 direct a subset 
of the translated personalization information to the older 
personalization equipment 130 and the remainder of the data 
to a post-processor 132 in the smart card programming 
device. 

The smart card personalization system 100 also provides 
a tracking/report module, or engine, 109 that collects sta- 
tistical information from the other modules in the system 
100 and formats the statistical information for output as 
hard-copy reports 154 or as input to a reporting function in 
the card issuer management system 150. Because this sta- 
tistical information is being gathered in real-time, the card 
issuer management system 150 can interactively query 
tracking/report module 109 to obtain statistics about the 
smart card personalization system as it is executing. 
Examples of items monitored by the tracking/report module 
109 are shown in FIG. 14. 

In an alternate embodiment shown in FIG. 2, the smart 
card personalization system 100 includes a security source 
in the form of a secure key manager module 111 and secure 
key database 128. When a smart card is manufactured, the 
vendor includes security architecture on the chip to prevent 
unauthorized programming. 'ITie security architecture imple- 
mentation is commonly dependent on the applicalion(s) 
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programmed onto the chip. For example, the secure keys 
programmed in a stored value application would be different 
than the secure keys programmed in a health care applica- 
tion. TTie security architecture implementation also varies 

5 depending on the type of card: some cards require a single 
secure key which enables chip programming while others 
require multiple secure keys to enable chip programming 
and to perform additional security functions. FIG. 2 illus- 
trates the basic functions of the secure key manager 111 

10 when interfacing with the security architecture on a card that 
requires multiple secure keys. 

As shown in FIG. 2, the secure key data is stored in the 
secure key database 128 which is external to the smart card 
personalization system 100 and maintained by the card 

15 issuer or other security source. Extending the secure key 
manager 111 to handle more or fewer secure keys, and to 
interface with a secure key database managed by the smart 
card personalization system 100 itself, is dependant on the 
application, operating system, and personalization cquip- 

20 ment being used in the specific card issuing application, and 
will be apparent to those skilled in the art. 

The secure key manager 111 also provides additional 
mechanisms to ensure secure key data authentication, data 
integrity and data secrecy. In one embodiment, secure key 

25 data authentication is accomplished through the implemen- 
tation of various encryption methods. Secure key data integ- 
rity is achieved through digital signature mechanisms that 
use public keys to ensure that secure key data is being 
transmitted and received from valid sources. Secure key data 

30 secrecy is ensured by encrypting the transmitted data with a 
private key that is shared with the data receiver and which 
the data receiver uses to decrypt the data upon receipt. 

After the system 100 receives a secure key record from 
the secure key database 128, the secure key manager 111, in 

35 conjunction with the card operating system interface 103 
and the card application interface 105, perform the secure 
key authentication, data integrity and data secrecy functions. 
The system 100 then transfers the secure key data to the 
personalization equipment 130 through the personalization 

40 equipment interface 107 along with the other data for the 
card. 

In an alternate embodiment, the secure key manager 111 
passes security information to the other modules of the smart 
card personalization system 100. For example, portions of 

45 the card holder data, such as the PIN (Personal Identification 
Number) code, may be encrypted by the card issuer man- 
agement system 150 prior to passing the data to the smart 
card personalization system 100. The card issuer manage- 
ment system interface 101 retrieves the encryption key from 

50 the secure key database 128 through the secure key manager 
111, and decrypts the data prior to encoding or programming 
the PIN code into the magnetic stripe and/or the chip. 

In a further aUernate embodiment, the secure key manager 
111 is a code "hook" into the smart card personalization 

55 system 100 which provides a gateway connection for an 
external security source that supplies the required security 
functions. An example of such an external security source is 
a security manager program written by a third party that 
manages a security database of secure keys and/or security 

60 functions similar to secure key database 128. The security 
functions may be either external routines executed by the 
security manager, or code modules passed by the security 
manager which are then executed by the smart card person- 
alization system 100 to provide the required security 

65 functions, or a combination of both. 

FIG. 3 illustrates a minimal configuration of the smart 
card personalization system 100. In this embodiment, only 
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the card issuer management system interface modules 101 
and the personalization equipment interface modules 107 are 
enabled in the software. This embodiment permits card 
issuer to use the system 100 to personalize non-smart cards, 
thus saving the cost of having two separate personalization 
systems, while permitting the card issuer to use multiple data 
formats and multiple types of personalization equipment. 
FIG. 3 also illustrates an additional alternate embodiment 
that includes the tracking/report module 109 as described 
above in conjunction with FIG. IC. 

In a still further alternate embodiment, the smart card 
personalization system 100 shown in FIG. 3 encodes data 
onto an optical transaction card when optical-encoding 
equipment is used as the personalization equipment 130. 

FIGS. 4 and 5 depict still further alternate embodiments 
that are implemented when the card issuer does not program 
a card application on the smart card chip. These embodi- 
ments allow the card issuer to issue multiple card types with 
their attendant variety of operating systems on multiple 
types of personalization equipment without having to recon- 
figure the smart card personalization system 100. As 
described above in conjunction with FIG. IC, FIG. 4 
includes the modules that support reporting and post- 
processing. FIG. 5 illustrates the embodiments of FIG. 4 
with the addition of the secure key manager module 111 that 
provides security to the card operating system interface 103 
for transmission to the personalization equipment 130, 

Similarly, FIGS. 6 and 7 illustrate embodiments to sup- 
port a card issuer that uses the chip on a smart card only as 
a data storage device for a card application, and so does not 
have an operating system executing on the chip. Smart card 
personalization system 100 supports multiple card applica- 
tions for multiple card types issued with multiple types of 
personalization equipment. FIGS. 6 and 7 are analogous to 
FIGS. 4 and 5 except that the secure key manager 111 
provides secure keys and/or functions to the card application 
interface 105 instead of the card operating system interface 
103. 

FIG. 8 is a high level flow chart for one embodiment of 
software which implements the functions of the smart card 
personalization system 100 described above. The software 
acquires a personalization equipment identifier for a batch of 
transaction cards to be issued from the card issuer manage- 
ment system at block 801. Depending on the type of cards 
to be issued, the software also acquires a program applica- 
tion identifier(s) and/or a card operating system identifier at 
the same time. The software then acquires the particular data 
format template corresponding to the format of the person- 
alization data through one of the procedures described above 
(block 803), At block 805, the system acquires the equip- 
ment characteristics for the personalization equipment to be 
used to issue the batch of cards from the personalization 
equipment record specified by the perst)nalization equip- 
ment identifier. 

If a card operating system identifier was passed by the 
card issuer management system (block 807), the software 
retrieves the programming control commands from the card 
operating system database record corresponding to the card 
operating system identifier at block 809. Blocks 811 and 813 
perform the same logic for a card application, retrieving the 
application data, such as code and/or variables, from the 
database. At this point, the software has acquired the com- 
mon data necessary for all the cards in the batch and begins 
looping through the logic which issues cards for the indi- 
vidual cardholders. 

'llie card issuer management system passes the personal- 
ization data for a single card holder to the software (block 
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815) which translates the data items from the format defined 
by the data format template into an internal format used by 
the modules of the smart card personalization system (block 
817). If the card chip contains security architecture that 

5 requires secure keys (block 819), the software acquires the 
secure key data necessary to perform the secure key func- 
tions from the appropriate secure key source at block 821. 

The software is now ready to transfer data to the person- 
alization equipment to program the card. If the card is 

10 protected by secure keys, the secure key functions are 
performed and the secure key data is transferred at block 
823. Then the programming control codes for the chip 
operating system, if applicable, are transferred (blocks 825 
and 827); next the application code and/or variables are 

15 transferred if they are needed (blocks 829 and 831). Finally, 
the card holder's personalization data that was translated 
into the internal format is transferred (block 833). 

After the data has been transferred to the card, the 
software adds the appropriate values to the statistics it 

20 collects for the card issuer management system at block 839. 
If more cards in the same batch remain to be issued (block 
841), the software returns to block 815 and acquires the 
personalization data for the next card holder. Otherwise, the 
software determines if the card issuer management system 

25 has a different batch of cards to issue (block 843) and returns 
to block 801 to acquire the necessary information to repeat 
the cycle for the new batch. If no further cards are to be 
issued, the software exits. 
The mechanisms by which the card issuer management 

30 system 150 passes the necessary data to the smart card 
personalization system 100 and the order in which the smart 
card personalization system processes the data from the card 
issuer management system may be changed without exceed- 
ing the scope of the invention. Different arrangements are 

35 dictated by the specific environment in which the system 
100 operates as shown in the alternate embodiment illus- 
trated in FIGS. 9 and 10. 

In FIG. 9, a security module 911 acts as a gateway into the 
smart card personalization system 100 for a security source 

40 such as security manager 940 and security database 942 
shown in FIG. IB as 111 and 128 respectively. TTie security 
manager 940 controls access to the security database 942 
and connects into the security gateway 911 to perform the 
necessary security functions for the smart card personaliza- 

45 tion system 100. The security gateway 911 is coupled to the 
card issuer management system interface 901 which allows 
the interface 901 to request that the security manager 940 
decrypt personalization data passed in an encryption format 
by the card issuer management system 950. The security 

50 gateway 911 is also coupled to the card application interface 
903 and the card operating interface 905 so that it can supply 
the necessary secure keys and/or security functions to those 
interfaces as explained above in conjunction with FIG. 2. 
Furthermore, the embodiment of the smart card person- 

55 alization system 100 shown in FIG. 9 acquires the applica- 
tion data 922 specified by the application program identifier 
prior to acquiring the programming control commands spe- 
cific to the card operating system 924 using the card iden- 
tifier. This embodiment permits the personalization data and 

60 the application data to be translated into the internal format 
prior to retrieving the programming commands for the card 
operating system 924 and the equipment characteristic data 
926, thus speeding the processing of each smart card. 
Standard transaction cards have data printed and 

65 embossed on the surface of the card and/or data encoded in 
a magnetic stripe on the card. With a smart card, data may 
also be stored in an internal memory area within the micro- 


02/20/2004, EAST Version: 1.4.1 


5,8! 

13 

processor. The same data may be placed on the surface of the 
card, in the magnetic stripe and also in the chip memory. The 
exact configuration of the data in and on the card will vary 
depending on the type of smart card being issued and the 
requirements of the card issuer. 

FIG. 10 is a high level flow chart of the embodiment 
shown in FIG. 9 and, in conjunction v^lh FIGS, 11, 12 and 
13, further illustrates how different mechanisms may be used 
to implement the smart card personalization system 100. The 
card issuer management system 950 passes a card frame- 
work template that defines the configuration of the smart 
card to the smart card personalization system 100 at block 
1001. 

FIG. 11 illustrates one embodiment of the data layout for 
the card framework template record UOO. The micropro- 
cessor chip identifier 101 and the card operating system 
identifier 1102 (if present) are specific to the type of smart 
card to be issued. The master file definition 1103 contains 
control information such as the chip source and the last date 
the chip was altered. The system file definitions 1104, 1105, 
1107 contain addresses for the location of the system files 
within the memory of the chip. The system files are used by 
the card operating system and contain information such as 
the PIN code(s) for the card and applications, and algorithm 
tables, in the embodiment shown in FIG. 11, the master file 
and the system file definitions conform to the International 
Standards Organization (ISO) directive number 7816-4. 

The next three sections of the card framework template 
record 1100 define the arrangement of data on the surface 
and magnetic stripe of the card. If information is to be 
printed on the card, such as the card holder's photograph 
1109, the location on the surface of the card to print such 
data is passed by the card issuer management system 950 in 
the printing template of the card framework template record 
1100. Similarly, the locations on the surface of the card to 
emboss data is passed in the emboss template, and the 
arrangement of the data to be encoded in the magnetic stripe 
is passed in the mag stripe template. The emboss data is 
illustrated in the card framework template record 1100 as the 
card holder's name (EMName) 1111, account number 
(EMAcct) 1113, and expiration date (EMXdat) 1115 and the 
magnetic stripe data by the account number (MSAcct) 1117 
and the expiration date (MSXdat) 1119. The number of data 
items in the printing, emboss, and mag stripe templates will 
vary depending on the configuration of the smart card 
desired by the card issuer as will be apparent to those skilled 
in the art. 

If the card issuer wants card applications programmed 
into the chip in the smart card, the card issuer passes the 
application program identifiers to the smart card personal- 
ization system 100 in the sections 1121, 1123, 1125 of the 
card framework template record 1100. Each application may 
have specific security functions associated with it (1127, 
1129, 1131) and that information is also passed by the card 
issuer management system 950. The card framework tem- 
plate record 1100 also contains the personalization equip- 
ment identifier 1123 for the personalization equipment to be 
used to issue the smart cards. 

In an alternate embodiment, the smart card personaliza- 
tion system 100 stores commonly used card framework 
template records in an internal database so that the card 
issuer management system 950 needs to pass only a card 
framework template identifier that identifies which card 
framework template record is to be used for a particular 
batch of cards. 

'llie smart card personalization system 100 acquires the 
data format template for the personalization data from a 
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pre-defined location specified by the card issuer at block 
1003. If the card issuer has passed a data format identifier to 
the system 100, the data fonmate template record corre- 
sponding to the data format identifier is retrieved from the 

5 data format database 920. Alternatively, the card issuer may 
pass the data format template record itself When neither the 
data formal identifier nor the data format template record is 
passed to the system 100, the format of the personalization 
data is determined by the card application data as explained 
in more detail below. 

An example of a data format template record is shown in 
FIG. 12. The data format template record 1200 defines an 
hypothetical layout of the personalization data records in the 
card holder database 952 in which the account number 1201 
is the first field, the card holder's name 1202 is the second 

^5 field, and the expiration dale of the card 1205 is the third 
field. In one embodiment, the personalization data records 
are commadelimited records so no data field lengths are 
necessary to define the record format. 'ITius the data format 
template record 1200 shown in FIG. 12 completely defines 

20 the structure of the following example of a comma-delimited 
personalization data record to the smart card personalization 
system 100: 1 33444999 922,Mary Jane Smith, 0299. 

The smart card personalization system 100 acquires the 
application data for the card application, or applications, 922 

25 corresponding to the application program identifiers, if any, 
that were passed by the card issuer management system 950 
at block 1007. If no application program identifiers are 
passed, the smart card personalization system 100 acquires 
default application data (block 1008). The default and/or the 
application data in the card application data record(s) cor- 
responding to the application program identifier(s) are 
inserted into the corresponding sections, i.e., 1121, 1123, 
1125, of the card framework template record 1100. 

One embodiment of the layout of a card application data 
record is shown in FIG. 13. The first field in the card 

35 application data record 1300 is the application name 1301. 
As with other computer-based application programs, a card 
application processes data from external sources such as an 
automatic teller machine or internal sources such as data 
files encoded into the microprocessor's memory. Using the 

40 smart card causes the appropriate application to be executed 
by the microprocessor and the application, in turn, accesses 
the internal files to retrieve or store data. To access internal 
data, the card application data record contains pointers to 
application files in the chip memory (1302, 1305, 1037) and 

45 also the location of fields within the application files. Some 
of the fields are initialized with data from the card holder 
database 952 when the card is issued. The application data 
1300 includes an address 1303 to a card holder file located 
in the chip memory and defines the card holder file as 

50 containing three fields: the card holder's name (ICName) 
1309, the account number (ICAcct) 1311 and the expiration 
date (ICXdat) 1313. Additional internal data is stored in 
other application files and the layout of those additional files 
is also defmed by the application data 1300. 

55 If the chip embedded in the smart card contains an 
operating system as specified by the card framework tem- 
plate record, the smart card personalization system 100 
acquires a set of programming control commands for the 
operating system from the card operation system database 

60 924 at block 1011. The programming control commands for 
each operating system includes commands for functions 
such as creating and accessing files in the memory of the 
chip, reading and writing records in the files located in chip 
25 memory, along with security commands that authenticate 

65 PIN (Personal Identification Number) codes and control 
transactions that change monetary amounts stored in the 
chip. 
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The smart card personalization system 100 acquires the 
equipment characteristic data corresponding to the person- 
alization equipment identifier in the card framework tem- 
plate record from the personalization equipment database 
926 at block 1013. Included in the equipment characteristic 
data is a set of personalization programming control com- 
mands which control the operation of the personalization 
equipment. As is the case with the card operating systems, 
the personalization control commands are proprietary to the 
vendor of the equipment but typically include commands 
directed to the administration, formatting, and production of 
smart cards. 

When the smart card personalization system 100 has 
acquired all the data necessary to define a smart card, it is 
ready to accept personalization data records 952 from the 
card issuer management system 950. As each personaliza- 
tion data record 952 is passed at block 1015, the smart card 
personalization system 100 uses the data format template, if 
present, to translate the personalization data into an internal 
format, and the card application data and card framework 
template to map tbe personalization data into variables in a 
command script written in an internal scripting language at 
block 1017. The translation and mapping process is 
described further below. Alternate embodiments which use 
a standard programming language such as Basic, Java or C 
instead of the internal scripting language are within the 
scope of the invention. 

The smart card personalization system 1019 checks for 
security requirements for the various components of the 
smart card issuing process. In the embodiment of the card 
framework template shown in FIG, 11, the security require- 
ments for the applications are specified by the card frame- 
work template record 1100 at block 1019. If there are 
security requirements, the smart card personalization system 
100 acquires secure data and/or functions from the security 
manager 940 and adds the functions into the internal script 
at block 1021. An aUernate embodiment of the smart card 
personalization system 100 passes the identifiers of the card 
operating system and the personafization equipment, as well 
as the application program identifier, to the security manager 
940 which retrieves the appropriate security data and/or 
functions from the security database 942. The security 
functions typically use data from additional sources, includ- 
ing data stored in internal chip files, personalization data 
952, the operating system database 924, the card application 
database 922, combined with the algorithm tables stored in 
the chip or from an external security module, such as the 
security manager 940, to perform the secure key 
authentication, data integrity, data secrecy and other security 
processes described above in conjunction with FIG. 2. 

Once the internal command script is completed, it must be 
translated into the proprietary programming control com- 
mands native to the card operating system (if present) and to 
the personalization equipment so that the personalization 
data is transferred to the smart card. In this embodiment, the 
translation is performed by a script language interpreter at 
blocks 1025 and 1027 using the information acquired from 
the card of)erating system database 924 and the personal- 
ization equipment database 926. 

At block 1029, the smart card operating system 100 
passes the interpreted script to the personalization equip- 
ment which then executes the programming control com- 
mands to emboss/print, encode and program the appropriate 
personalization data onto the surface, and into the magnetic 
stripe and chip respectively of the smart card. As before, if 
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the card issuer has elected to purchase an add-on smart card 
programming device to attach to its existing personalization 
equipment, an altemate embodiment of the smart card 
personalization system 100 directs the control commands for 
^ the embossing and encoding to the personalization equip- 
ment 930 and the control command for the chip to the 
post-processor 132 in the smart card programming device. 

When the issue process has been completed for one card, 
10 the smart card personalization system 100 acquires the next 
personalization data record if there are additional cards of 
the same type waiting to issue (block 1033). Otherwise, the 
smart card personalization system determines if there is 
another batch of smart cards of a different type waiting to 
15 issue (block 1001) and begin the issuing process again by 
acquiring a new card framework template record from the 
card issuer. 

'ITie following example uses sample data to further 
describe the processing performed by the embodiment of the 
smart card personalization system 100 shown in FIGS. 9 and 
10. The card issuer management system 950 requests the 
initiation of the issuing process by sending the smart card 
personalization system 100 a card framework template 

25 record, application program identifier's), a card operating 
system identifier, a personalization equipment identifier, and 
optionally a data format template identifer or a data format 
template record. In this example, the card issuer manage- 
ment system 950 passes an application resource template 

30 record shown below that contains the identifiers The system 
100 acquires a data format template using one of the 
procedures specified above and explained in more detail 
below in conjunction with the sample card holder data 
records. 


Apptication Resource Template Record 
[A3] 

DFT-CARDl.DFT 

CAT-CARDl.CAT 

CID-CHIPX.CID 

CPT-CARDl.CPT 

SOURCE-Al 


The first statement in the record marks the beginning of 
information for a particular application, in this case appli- 
cation "Al". The next four statements define the identifiers 
for the card fi-amework template record (DFT), the card 
application record (CAT), the card operating system record 
(CID) and the personalization equipment record (CPT). The 
final statement is the name of a file created by the card 
issuing management system 950 that contains the card 
holder data record(s). The card issuing management system 
950 inputs the card holder data as either a single request or 
a 'batch' of requests for cards to be issued. 

The system 100 retrieves the records corresponding to the 
identifiers from the database. The system 100 then uses the 
information contained in the card framework template and 

go data format template to set up an internal "script," which it 
later interpretes into the specific commands contained in the 
card operating system and personalization equipment 
records that instruct the personalization equipment to pro- 
cess the personalization data and issue the card for each card 

55 holder. 

Two sample card holder data records 952 are shown 
below. 
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Cardholder Data Records 

Smith^ames* 12653683091 245'0998'041052*mmmin 
Anderson,Sue*394850039841 3S*0297'1 10248"mmmm 


In these records, the format defined by the card issuer places 
the account name (card holder name) in the first field 
followed by the account number, expiration data, date of 
birth, and medical data. 

The system 100 uses the data format template to interpret 
each card holder data record 952 as it is processed. ITie 
system 100 also uses the data format template and card 
application records 922 to validate the data 952 ensuring 
proper data and format. An example of a data format 
template corresponding to the format of the sample card 
holder records shown above is shown in the first line of the 
table below. The James Smith personalization data record is 
included in the table to show the correspondence between 
the data format template and the fields of the card holder 
data record. The data format template equates each field in 
the card holder record with an internal label, %1, %2, etc., 
which corresponds to the internal order used within the 
system 100. 


Data Format Template Record 

I %1 I %2 |%3|%4|%5| 
Smith^ames* 12653683091 245*0998*041052*mmmm 


The example shown above represents the simplest case in 
which the fields of a card holder data record 952 are 
arranged in the internal order used by the smart card 
personalization system 100. This one-to-one correspondence 
means that the system 100 does not have to translate the card 
holder data fields into the internal field order In such a case, 
the data format template record is unnecessary. Thus, in a 
further alternate embodiment, the card issuer does not pass 
a data format identifier to the smart card personalization 
system 100, but instead passes an indicator, such as a flag, 
which informs the system 100 that no data format template 
is needed because the card holder data fields are in a 
one-to-one correspondence with the internal field order. The 
system 100 acts on the indicator by bypassing the translation 
step. 

A more complex example shown next is one in which the 
fields of the card holder data record 952 and the data within 
the fields are out of order relative to the internal system 
order. In this case, translation is necessary. 


Cardholder Data in Issuer Format 


1234567891245 James Smith 0998 041052 mm mm 
Cardholder Data Translated into Internal Format 


Smith,Jamcs'12653683091245'0998'041052*mmmm 


The system 100 uses the data format template to translate 
the data fields into the internal order as shown above. The 
translation may result in the physical rearrangement of the 
data fields or may be a logical rearrangement in which the 
data format template is invoked as a key each time a field 
from the card holder data record is referenced by the system 
100. Various data format templates designed to translate 
different arrangements of card holder data will be apparent 
to those skilled in the art as will the substitution of tables of 
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field equivalences or a set of parsing instmctions or other 
mechanisms for the simple table used above to illustrate this 
example. 

5 llie card framework template record describes the struc- 
ture of the chip on the card. In the sample shown below, the 
SMF entry defines a root directory (3F00), while $DF entries 
define a medical application (5F20), and an accounting 
application (5F10). Within each directory are application- 

30 specific files defined by $EF entries, such as 6F00 containing 
the account name and 6F10 containing the account number. 
All file descriptive data resides in the card framework 
template and is referenced at various times during the smart 
card issuing process. 


Card Framework Template Record 


SCHIP-3102>1EM-8192,SIZE-N10 
20 SMF PATH-x3F00,TAG-ROCT,TITLE-'Root Directory*,SIZE-D7194 
SDF PATH-x3F005F10,TAG-ACCT,TrrLE-*Acct Data', SIZE-D2048 
SDF PATH«x3F005F20,TACi-MED,TrrLE-' Medical •,SIZE-D1024 
SEF PATH-X3FO031 00,TAG«ICCrD,Tm.E-* Issuer 

ID',FORMAToT,SIZE=D10 
SBF PAra=x3P005 F205E00,TAG»MED1 ,TriXE»* Medical 

profUc',FORMAr=T,SlZE=D80 
25 SEF PAI^H=x3F005F106POO,TAG=NAME,TITLE-*Acct 

Name',FORMAr=T,SIZE=A30 
SEF PArH-x3F005F106F10,TAG=ACCnD,TrrLE=' Account 

No. ' ,FORMAr=T,SIZE-Nl 4 
SEFPArH-x3F005F106F20,TAG=EXPIRE,TrrLE=Expirc 

Datc'^RMAr=T,SIZE=N4 
30 SEF PArH-x3F005F106F30,TAG-BIRTH,TrrLE-' Account Holder 

Birthdate'.F0RMAr-T,SIZE-N6 


The card application record 922 "maps" the card holder 
35 data 952 to the data fields used by the application. The 
sample card application record 922 shown below has its data 
entries arranged in the sequence in which they arc processed 
by the smart card personalization system 100. 


Card Application Record 


$VL ICCID VALUE-1234509876 
$VL MEDl %5,TYPE-A 
$VL NAME %1,TYPE-A 
45 $VL ACCTID %2,TYPE-N 

$VL EXPIRE %3,TYPE-N 
$VL BIRTH %4,TYPE-N 
$VL FMTACCT %2(l-4)-%2(5-9)-%2Cl0-14) 


50 The ICCID entry contains the chip identifier. Each of 
remaining entries, except for FMTACCT, maps a "tag" to 
the field in the card holder data record 952 that am la ins the 
information (as defined in the data format template shown 
above) and specifies the type of data in the field. Thus, the 
MEDl tag represents the fifth field in the card holder data 
record 952 and the data is in alpha format. The FMTACCT 
entry breaks the second field in the card holder data record 
952, i.e., the account number, into sections and inserts 

60 hyphens between the sections. 

The card operating system record 924 contains the pro- 
gramming control commands necessary to program the chip 
on the card. The sample card operating system programming 
65 control commands shown below are taken from the ISO 
directive number 7816-4 and are not the internal proprietary 
commands of any particular card operating system. 
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Card Operating System Record 

SELECT A0A4000002%F 
WRTTE A0D0%O%L%D 
READ A0B0%O%L%D 
RESET VALUE-xFF 


Each entry in the example record above contains a tag 
followed by the corresponding command in the native 
language of the card operating system. Variable parameter 
fields are indicated by "%" followed by a letter and arc filled 
in with the appropriate card holder data as each individual 
card is processed. 

The personalization equipment record 926 contains per- 
sonalization equipment characteristic data, such as instruc- 
tions that define the actual sequence and steps necessary to 
issue a complete card on a specific set of personalization 
equipment. The sample instructions used in this example are 
fictitious and do not represent the internal proprietary 
instructions for any particular personalization equipment. 


Personalization Equipment Record 

SEMBOSS 

#EMB#%FMTACCT%'%NAME% 
SENCODE 

#ENC#%%%ACCnD%'%NAME% 

SIC 

@ICCID 
WRITE ICCID 
©NAME 
SELECT ACCT 
SELECT NAME 
WRFTE NAME 
@ACCnD 
SELECT ACCnO 
WRITE ACCnD 
©EXPIRE 
SELECT EXPIRE 
WRITE EXPIRE 

$PR 


As each card is issued, the personalization equipment 
characteristic data shown above is serially processed in four 
steps defined by the entries preceded by a "$." The card 
application record 922 is used to determine the value of the 
variable parameter fields in each instruction. 

The SEMBOSS instruction is a single stream of data that 
begins with the control sequence #EMB# which notifies the 
personalization equipment that the data that follows should 
be embossed on the card. Each data field in the instruction 
is enclosed in a pair of percent signs. In this case, the first 
data field is FMTACCT, or the formatted account field as 
defined in the card application record 922. ITie system 100 
searches the card application record 922 for the FMTACCT 
entry and creates the string "1265-36830-91245" from the 
second data field in the first sample card holder record 952. 
The next field, NAME, is taken from the first data field in the 
card holder record 952. Thus, the emboss instruction for the 
first sample card holder record 952 becomes #EMB%1265- 
36830-91245%%Smith,James%. 

The SENCODE instruction causes the system 100 to 
process the card holder data to be encoded on the magnetic 
stripe of the card in the same fashion as the emboss 
instruction. Additional control characters in accordance with 
following I ATA (International Air Travel Association) and 
ISO standards are inserted into the command, llie resulting 
instruction is #ENC#%%%12653683091245%%Smith, 
James%. 
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The SIC command specifies the information to be stored 
in the chip's memory. The card operating system record 924 
is used to translate the instructions in the personalization 
equipment record into the programming control commands 

5 for the operating system. A control sequence, #/@#. is used 
to notify the personalization equipment that the data that 
follows is chip data. The first field to be stored is the chip 
identifier, ICCID. The system 100 interprets the WRITE tag 
in the personalization equipment record 926 in accordance 

10 with the command identified with the WRITE tag in the card 
operating system record 924. Since no oflset value is speci- 
fied in the application record 922 for the chip identifier entry, 
the default of "0000" is loaded into the %0 variable param- 
eter field. The %L variable parameter field is set to the value 

15 of the SIZE field in the SCHIP entry in the card framework 
template, i.e., "10" or hexadecimal "OA." The %D variable 
parameter field is set to the value of ICCID, "1234509876". 
The resulting command is AODOOOOOOAl 234509876. 
The next commands cause the card operating system to 

20 store the card holder name into the account name file in the 
account directory on the chip. The system 100 translates the 
SELECT ACCr command into the corresponding card oper- 
ating system command. The system 100 locates the 
SELECT entry in the card operating system record 924, the 

25 ACCT entry in the card framework template record, and 
substitutes the specified directory path for the account 
directory defined in the ACCT entry, i.e. "5F10," for the %F 
variable parameter field in the command defined in the 
SELECT entry. The resulting command is 

30 AOA40000025F10. Similarly, the SELECT NAME com- 
mand causes the system 100 to substitute the account name 
file "6F0O" for the %F variable parameter field. The result- 
ing command is A0A40000026F00. The final command in 
this series is the WRITE command. The system 100 inter- 

35 prets the WRITE command by substituting the default offset 
of "0000" for %0, the value of the SIZE field, "30" or hex 
"IE," as defined by the NAME entry in the card framework 
template record for %L, and the card holder's name, "Smith, 
James" for the first sample card holder data record 952, for 

40 %D, to produce the command AODOOOOOlESmith, 

James where each "~" represents 

a trailing space inserted to pad the name out to thirty 
characters. 

The system 100 processes the remainder of the commands 
45 in the personalization equipment record 926 in a similar 
fashion to produce a contiguous string of data containing the 
commands to issue a card for the first sample card holder 
data record 952: 

#/@#AOD00OO0OA123459876AOA4OO0O025FlOAOA40 
50 000026FOOAOD000001ESmith, 

James A0A40000026F10A0 

A4000002E12653683091245AOA40000026 
F2040998. 

The SPR tx)mmand cau.ses the system 100 to send the 
55 command data stream to the personalization equipment. 
The data layouts shown in FIGS. 11, 12 and 13, and the 
sample data discussed in conjunction with the above 
example arc only examples used to illustrate the functioning 
of various embodiments of the smart card personalization 
60 system 100. That the layouts and data are necessarily defined 
by the environment in which they are used will be apparent 
to those skilled in the art. 

As will also be apparent to those skilled in the art, the 
smart card personalization system 100 encompasses alter- 
65 nate embodiments of the software program in which the 
functions of the system are performed by modules different 
than those shown in the FIGS. The system KM) may process 
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the data in a serial or parallel fashion, or a combination of 
the two, without departing from the spirit or scope of the 
invention. The software program may be written in one of 
several widely available programming languages and the 
modules may be coded as subroutines, subsystems, or 5 
objects depending on the language chosen. Similarly, data 
used by the system 100 is described and represented as 
logical records embodied in a database but the invention is 
not limited to the described arrangement of data records, nor 
is the use of any particular type of data management system lO 
implied. Relational database systems from vendors such as 
Oracle, Sybase, Informix, or Microsoft provide the neces- 
sary infrastructure for managing the underlying data in the 
system, whether it is centralized or distributed, but other 
organizational data structures, i.e., indexed flat files, may be 15 
substituted without exceeding the scope of the invention. 

Furthermore, alternate embodiments of the invention 
which implement the system in hardware, firmware, or a 
combination of both hardware and software, as well as 
distributing the modules and/or the data in a different fashion 20 
will be apparent to those skilled in the art and are also within 
the scope of the invention. 

It is to be understood that the above description is 
intended to be illustrative, and not restrictive. Many other 
embodiments will be apparent to those of skill in the art 25 
upon reviewing the above description. ITie scope of the 
invention should, therefore, be determined with reference to 
the appended claims, along with the full scope of equivalents 
to which such claims are entitled. 

What is claimed is: 30 

1. A method for issuing portable programmed data carri- 
ers comprising: 

acquiring a personalization equipment identifier and per- 
sonalization data for a card holder from a card issuer 
management system; 

acquiring equipment characteristic data for a personaliza- 
tion equipment type from a record in a database iden- 
tified by the personahzation equipment identifier; and 

transferring the personalization data to personalization 
equipment as specified by the equipment characteristic 
data for the type of personalization equipment to issue 
the data carrier. 

2. The method of claim 1, further comprising translating 
the personalization data into an internal format such that the 
translated personalization data is transferred to the person- 
alization equipment. 

3. The method of claim 2, wherein the personalization 
data is translated from a format defined by the card issuer 
management system into the internal format in accordance 
with format template data. 

4. ITie method of claim 3, further comprising acquiring 
the formal template data from a record in the database 
identified by a data format identifier supplied by the card 
issuer management system. 

5. The method of claim 3, further comprising acquiring 
the format template data from the card issuer management 
system. 

6. The method of claim 3, further comprising acquiring 
the format template data from an application data record in 
the database identified by an application program identifier 
supplied by the card issuer management system. 

7. The method of claim 1, further comprising: 
collecting information regarding the issuing of the data 

carriers; and 55 
reporting statistics derived from the collected information 
to the card issuer management system. 


22 

8. The method of claim 1, further comprising: 
acquiring an application program identifier from the card 

issuer management system; 
acquiring application data from a record in the database 

identified by the application program identifier; and 
transferring the application data to the personalization 

equipment as specified by the equipment characteristic 

data. 

9. The method of claim 1, further comprising: 
acquiring security data from a security source; and 
transferring the security data to the personalization equip- 
ment as specified by the equipment characteristic data. 

10. The method of claim 1, further comprising: 
acquiring a card operating system identifier from the card 

issuer management system; 
acquiring programming control commands from a record 
in the database identified by the operating system 
identifier; and 

transferring the programming control commands to the 
personalization equipment as specified by the equip- 
ment characteristic data. 

11. The method of claim 10, further comprising: 
acquiring an application program identifier from the card 

issuer management system; 
acquiring the application data from a record in the data- 
base identified by the application program identifier; 
and 

transferring the application data to the personalization 
equipment as specified by the equipment characteristic 
data. 

12. A system for issuing portable programmed data car- 
riers comprising: 

a card issuer management system interface for acquiring 
a personalization equipment identifier and personaliza- 
tion data for a card holder from a card issuer manage- 
ment system; 

a personalization equipment interface for acquiring equip- 
ment characteristic data for a personalization equip- 
ment type from a record in a database identified by the 
personalization equipment identifier; and 

the personalization equipment interface for further trans- 
ferring the personalization data to personalization 
equipment as specified by the equipment characteristic 
data for the type of personalization equipment to issue 
the data carrier. 

13. The system of claim 12, wherein the system further 
acquires format template data from a record in a database 
identified by a data format identifier supplied by the card 
issuer management system and translates the personalization 
data into an internal format from a format defined by the 
format template data such that the personalization equip- 
ment interface transfers the translated personalization data to 
the personalization equipment. 

14. The system of claim 12, further comprising a tracking/ 
report engine for collecting data from the system regarding 
the issuing of the data carriers and for reporting the collected 
data to the card issuer management system. 

15. The system of claim 12, further comprising: 

a card application interface for acquiring application data 
from a record in the database identified by an applica- 
tion program identifier acquired by the card issuer 
management system interface; and 

the personalization equipment interface for further trans- 
ferring the application data to the personalization 
equipment as specified by the equipment characteristic 
data. 
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16. The system of claim 12, further comprising a security 
manager for acquiring security data from a security source 
and transferring the security data to the personalization 
equipment interface. 

17. The system of claim 12, further comprising: 

a card operating system interface for acquiring program- 
ming control commands from a record in a database 
identified by a card operating system identifier acquired 
by the card issuer management system interface; and 

the personalization equipment interface for further trans- 
ferring the programming control commands to the 
personalization equipment as specified by the equip- 
ment characteristic data. 

18. The system of claim 17, further comprising: 

a card application interface for acquiring application data 
from a record in the database identified by an applica- 
tion program identifier acquired by the card issuer 
management system interface; and 

the personalization equipment interface for further trans- 
ferring the application data to the personalization 
equipment as specified by the equipment characteristic 
data. 

19. A data structure stored on a storage device for pro- 
ducing portable programmed data carriers comprising a 
plurality of personalization equipment elements, wherein 
each persona Hzation equipment element is addressed by a 
unique personalization equipment identifier and specifies 
operating parameters for a type of personalization equip- 
ment such that the personalization data is properly formatted 
for transmission to the personalization equipment used to 
issue the data carrier, 

20. The data structure of claim 19, further comprising a 
plurality of data format elements, wherein each data format 
element is addressed by a unique data format identifier and 
specifies a template used by a card issuer to format person- 
alization data. 

21. The data structure of claim 19, further comprising a 
plurality of card operating system elements, wherein each 
card operating system element is addressed by a unique card 
operating system identifier and specifies programming con- 
trol commands for transmission to the personalization equip- 
ment. 

22. The data structure of claim 19, further comprising a 
plurality of application program elements, wherein each 
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application program element is addressed by a unique appli- 
cation program identifier and specifies application data used 
by a particular type of application program for transmission 
to the personalization equipment. 

5 23. The data structure of claim 22, further comprising a 
plurality of card operating system elements, wherein each 
card operating system element is addressed by a unique card 
operating system identifier and specifies programming con- 
trol commands for transmission to the personalization equip- 

'° mem. 

24. A system for issuing portable programmed data car- 
riers comprising: 
personalization equipment receiving a data stream and in 
35 response thereto personalizing portable programmed 
data carriers; 

personalization data obtained from a card issuer manage- 
ment system; and 

a smart card personahzation system having a database 
20 containing one or more data elements selected from the 
group consisting of 
data format template elements, 
card application data elements, 
card operating system elements, 
25 and personalization equipment elements, 

wherein the smart card personalization system outputs the 
data stream as a result of processing the personalization 
data as directed by at least one of the selected data 
elements. 

■"^ 25. A method for issuing portable programmed data 
carriers comprising: 

acquiring personalization data for a card holder and 
equipment characteristic data; and 
35 transferring the personalization data to personahzation 
equipment as specified by the equipment characteristic 
data to issue the data carrier. 
26. A system for issuing portable programmed data car- 
riers comprising a system interface for acquiring personal- 
40 ization data for a card holder and equipment characteristic 
data, and for further transferring the personalization data to 
personalization equipment as specified by the equipment 
characteristic data to issue the data carrier. 

♦ ♦ ♦ ♦ ♦ 
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[57] ABSTRACT 

A secure memory card includes a microprocessor on a 
single sexhiconductor chip and one or more non-volatile 
addressable memory chips. The microprocessor chip 
and non-volatile memory chips connect in common to 
an internal card bus for transmitting address, data and 
control information to such non-volatile memory chips. 
The microprocessor includes an addressable non- 
volatile memory for storing information including a 
number of key \^ues, application specific configuration 
information and program instruction information. Each 
chip's memory is organized into a number of blocks or 
banks and each memory chip is constructed to include 
security control logic circuits. These circuits include a 
number of non-volatile and volatile memory devices 
which are loaded with key and configuration informa- 
tion under the control of the microprocessor only after 
the microprocessor has determined that the user has 
successfully performed a predetermined authentication 
procedure with a host computer. Thereafter, the user is 
allowed to read out information from blocks only as 
defined by the configuration information. 

26 Claims, 5 Drawing Sheets 
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hold both programs and data. While password protec- 
SECURE MEMORY CARD tion is often used in these systems, it does not com- 

r^A^^r^^^, pletely protect sensitive data because, first, the authenii- 

BACKGROUND OF THE INVENTION ^on ^cnt is itself vulnerable However, more signifi- 

1. Technical Field ^ cantly, the disk drive containing the data can be physi- 
This invention relates to the field of portable personal removed and accessed in a setting more conducive 

computers and more particulariy to maintaining systems to data analysis. In this case, only some form of encryp- 
for data security in a portable digital information envi- . tion is capable of protecting the data. The nature of disk 
ronment access makes this possible without undue performance 

2. Description of the Prior Art or cost barriers. An example of this type of system is 
The security of personal information has forever been described in U.S. Pat No. 4,985,920 cntiUed, "Inte- 

a concern. It has been (ensured by locks, codes and grated Circuit Card." 

secret pockets. As information has taken new forms. The recent emergence of the flash memory and re- 
new methods have been required to meet the changed movable 'Wmory cards" has allowed major reductions 
sitiwtions. ^5 in size and power requirements of the portable com- 

Mistoncally, secunty of information has been ad- puter. The flash memory combines the flexibility of 
dressed by use of signatures, credcntiak and photo- random access memory (RAM) with the permanence of 
graphs, ecctromc devices such as automatic banking disks. Today, the coupling of these technologies aUows 
machines ^veadd^ encoded cards and personal iden- up to 20 miUion bytes of data to be contain^ without 
S.^r^^IJIIl^'^J^™^ needofpower.inacredHcardsize,removablepackage. 

Ma^^nZT^ contoue to usepasswords. This data can be made to appear to a host systeTeither 
secS ^ ^n^i^C ^ ^"^^ has been used as a as if it were contained in a ^entional disk drive or as 
secunty tool. The Smart Card is a ftmflli microcom- ir ;* . . _* • r i_ ^ 

puter 4h writable, non-volatile memoTanTa^p^e LLnfoL^ h host's memory. These 

input/output interface, fabricated as a 2ngle chiWd 25 ^»^°logi«d developments have made further reduc 
oibedded in a plastic^'credit card". It has «terioK ^V*^ P^^^I? ^ «t«it that it may be 

to allow it to be connected to specially desi^^d^ ^ "^.^^^^^ rather than ma handbag or briefcase, 
ment. The program contained Sthe card's^crSoi^ Thus, the data and its host system have become more 
puter interacts with this equipment and allows its non- ^"^^ble to loss or theft and sunultaneously more 
volatile memory data to be read or modified according 30 <""icult to protect memory data by encryption as this 
to the desired algorithm which may optionally include P'^^^s major cost and performance barriers, 
a password exchange. Special techniques have been Accordingly, it is a pnmary object of the invention to 
implemented to protect the memory information and to Provide a portable digital system with a secure memory 
allow varied permissions according to the situation. For subsystem. 

example, U.S. Pat. No. 4,382,279 entitled, "Single Chip 35 ^ another object of the invention to provide a 
Microprocessor with On-Chip Modifiable Memory" memory card which can be protected if removed from 
discloses an architecture which permits automatic pro- * portable digital system. 

gramming of a non-volatile memory which is included \^ ^ fiirther object of the present invention to 

on the same chip as a processing and control unit. As in provide a memory card in which tiic chips of the card 
other systems, the microprocessor only protects mem- 40 protected if removed from such card. 

^'ll^^'^^^Sj'iusbeenusedbothtofaciliUtethe ^^^^ OF THE INVENTION 

process of identification and to be the actual site of the above objects are achieved in the secure card of 

valued information. In this situation, as in most past a preferred embodiment of the present invention. The 

situations, physical presence of a "key" as well as some 45 secure memory card includes a microprocessor on a 

special knowledge has been used as part of the verified- single semiconductor chip and one or more non- volatile 

tion or authentication process. In such above cases, addressable memory chips. The microprocessor chip 

identification has been a dialog between the person and nonvolatile memory chips connect in common to an 

desiring access and a ifixed agency such as a security internal card bus for transmitting address, data and 

giiard or an automatic teller machine. 50 control information to such non-volatile memory chips. 

The current state of portability of freestanding com- The microprocessor includes an addressable non- 

puting devices makes it possible for both the physical volatile memory for storing information including a 

key and the authentication agent to be small, portable number of key values, configuration information and 

and hence more subject to loss or theft. Further, com- program instruction information for controlling the 

puting devices make it possible to perform repeated 55 transfer of address, data and control information on the 

attempts to guess or deduce the special knowledge or internal bus. The chip memory is organized into a num- 

password associated with the identification process. ber of blocks or banks, each block having a plurality of 

This is especially true if the authentication agent or addressable locations. 

device is also in the control of the thief or burglar. To According to the present invention, each memory 
make matters worse, technology now allows and en- 60 chip is constructed to include security control logic 
courages the carrying of enormous amounts of sensitive circuits. In the preferred embodiment, these circuits 
information in a pocket or handbag where it is subject include a non-volatile lock memory, a non-volatile lock 
to mishap. storage enable clement and a volatile access control 
Today, notebook and subnotebook sized computers memory, each being loadable under the control of the 
provide a capable freestanding environment which al- 65 microprocessor. More specifically, the microprocessor 
lows for significant computing power and thus creates a first loads a lock value into the non-volatile lock mem- 
need for additional data storage capabaity. This has ory and resets the lock storage enable element inhibiting 
mitially been met by miniature hard disk devices which access. Thereafter, the microprocessor loads the access 
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control memory as specified by the configuration infor- power from a powered off condition, access is blocked 
mation. Such information is loaded only after the micro- to protected memory contents until the first authentica- 
processor has determined that the user has successfully tion is successfully performed, 
performed a predetermined authenticatios procedure Thus, if either the memory card or its host processor 
with a host computer. The security logic circuits of S is lost, stolen, powered off or left unattended, the mem- 
each memory enable the reading of information stored ory*s data is protected from access, either immediately 
in selected addressed blocks of the flash memory as a or as soon as the current periodic authentication ex- 
function of the configuration information loaded into pires. In the event of theft, the memory data is protected 
the memory chip's access control memory. Periodi- from access even if the memory card is opened and 
cally, the user is required to successfully perform an 10 probed electronically or the memory chips are removed 
authentication procedure with the host computer, and and placed in another device, 
the user is allowed to continue reading information as The above objects and advantages of the present 
allowed by the access control memory. In the preferred invention will be better understood from the following 
embodiment, the host computer is coupled to the mem- description when taken in conjunction with the accom* 
ory card through a standard interface such as the inter- IS panying drawings. 

face which conforms to the Personal Computer Mem- ^rr^ * 

ory Card International Association (PCMCIA) stan- DESCRIPTION OF THE DRAWING 

dards, FIG. 1 shows an overall block diagram of a system 

The present invention melds the "SmartCard" and which incorporates the memory card constructed ac- 

"memory card" technologies which is key to allowing 20 cording to the present invention, 

the protection of the large amounts of data made possi- FIG. 2 shows in greater detail, the access control 

ble by the flash memory technology in the "security processor (ACP) of FIG. 1 including a layout of its 

harsh" environments which electronic miniaturization non-volatile memory. 

has created. Further, the present invention is able to FIG. 3 shows a detailed block diagram of a standard 

take advantage of improvements and enhancements in 25 flash memory of FIG. 1 modified according to the pres- 

both technologies. ent invention. 

Additionally, the security logic circuits of the present FIGS. 4 and 5 are flow charts used to explain the 

invention are incorporated into and operate in conjunc- operation of the memory card of the present invention 

tion with the flash memory in a way that minimizes the in carrying out various authentication procedures, 

amount of changes required to be made to the basic 30 t^^o^^,^^^, 
logic circuits of the flash memory. More specifically, 

the flash memory can be operated in a secure mode and EMBODIMENT 
in a non-secure mode wherein the security logic circuits FIG. 1 is a block diagram of a secure portable hand- 
are bypassed enabling the flash memory to operate as if held computing system 1 usable as a personal computer 
such circuits had not been installed. The non-secure 3S or as a transaction processor. System 1 includes a mem- 
mode is normally entered when the contents of the flash ory card 3 constructed according to the present inven- 
memory's non-volatile lock memory are cleared. This is tion which connects to a host processor 5 by a bus 102. 
generally indicative of an unprogrammed or fully The host processor 5 may take the form of a pahn top 
erased flash memory which naturally erases to a prede- personal computer, such as the HP 95LX manufactured 
tcrmined state O-e. an all ONES state). 40 by Hewlett-Packard. The host processor 5 includes a 
With the addition of a small amount of logic to the liquid crystal display (LCD) 5-2, a keyboard 5-4, a mi- 
flash memory and an "Access Control Processor" croprocessor 5-^, a memory 5-8 and a serial interface 
(ACP) , the contents of the flash memory is made secure 5-10 all coupled in common to a bus 106. The memory 
without requiring data encryption. Therefore, the m- 5-8 includes a one megabyte read only memory (ROM) 
vention eliminates the overhead of encrypting and de- 43 and a 512 Kbyte random access memory (RAM), 
crypting data which can be quite time-consuming for The connection between the memory card 3 and host 
large blocks of data. processor 5 is established through a standard bus inter- 
In operation, the ACP periodically prompts the user face. In the preferred embodiment, the bus 102 con- 
of the system for entry of some forxn of authentication. forms to the Personal Computer Memory Card Intema- 
This may be a password, a PIN, a specific pen computer 50 tional Association (PCMCIA) standard. The interface 
"gesture" performed at a specific point on the writing 102 provides a path for transferring address, control and 
surface, a spoken command or a '^voiccprint" of the data information between host processor 5 and the 
user. The method varies with the system. The program- memory card system 3 via a standard interface chip 104 
mable ACP allows the user to alter the specific content and a memory card bus 105. Each of the buses 102, 105 
of the authentication and the frequency of prompting. SS and 106 include a data bus, a control bus and an address 
The code for authentication and the data required by bus and provide continuous signal paths through all like 
the lock and access control memories are stored within buses. For example, bus 105 includes address bus 105a, 
the ACP*s non-volatile memory which is on the same data bus 105^, and control bus 105c 
chip as the ACP and, hence, are protected. The PCMCIA bus standard has evolved from a stan- 
As mentioned, a successful authentiflcation causes the 60 dard which supports disk emulation on memory cards 
ACP to enable, or continue to enable, all or selected to a substantially different standard which allows ran- 
blocks of the flash memory for access. Failure causes dom access to memory data. The memory card of the 
access to the flash memory to be disabled. Thus, the present invention provides a protection technique 
operation is similar to a "dead man throttle" in that any which supports this new standard by providing rapid 
failure to successfully complete authentication will 65 access to random memory locations without resort to 
cause the flash memory's data to be protected. In addi- encryption techniques. By controlling the data paths 
tion, a conunand initiated by the user can also cause which carry the data from the memory array to the 
access to be disabled. Further, upon first application of host, the memory card of the present invention protects 
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the data without imposing any time-consuming bufTer- 

ing. decryption or other serial processing in this path, FLASH MEMORIES 103a through 103/i 

Typically, a user operates system 1 from the key- FIG. 3 is a detailed block diagram of flash memories 
board $-4 to perform the typical operations such as 103a through 103rt. Only the detailed logic circuits of 
spreadsheet and database functions which display infor- 5 memory 103a are shown since memories 103* through 
mation on display M and update information stored in 103fl are constructed identically to memory 103a. 
files in memory card 3. The host processor 5 sends The flash memory 103a basically comprises two sec- 
address information over bus 102 to retrieve informa- tions, a section containing the security access control 
tion and ifdesired, updates the information and sends it. circuits of the present invention and another section 
along with the n«;essary address and control informa- containing the basic or standard logic circuits of the 
tion back to memory card 3. flash memory. 

As shown in FIG. 1. the memory card 3 of the pres- 
ent invention includes an access control processor Security Access Control Section 
i^S^l 1? coupled to bus 105 and a number (n) of 15 As seen from HG. 3. the security control circuits of 
CMOS flash memory chips 103a through 103«. each the present invention include a 32-bit key register, a 
coupled to bus 105. ACP 10 is typically the same type of 32-bit volatile lock register 33. a 12-bit deUy counter 32. 
ffiS^^ v^"°"^ as used in the "Smart Card". Tlie . comparator circuit 39. an all ONES detected signal 
CMOS ftash memones 103a through 103i, may take the circuit 38. a non-volatile lock memory 35. a one-bit 
form offish memory chips manufactured by ^ 20 non-vohitile lock storage enable dement 36, a volatile 
poration. For example, they make take the formof ti« ^ control memory 43. an access modification aUow 
toel flash memory chip <l<^g^^^ ^^ll^^l^^ AND gate 34 and an output OR gate 45 arranged as 
S f ^ ^ receives com- 

SpTlJSi^J >f .T^^^ „ mandcontrolsignalsdesignatedbyvarioushexadecimal 

mclude 32 CMOS flash memories, that IS n = 32. 25 , , -*«t*^l i.?a7TN > 

viuwww. uwi u u values (e.g. 31H through 38H) from a command register 

ACCESS CONTROL PROCESSOR 10 50 included in the basic logic section. These signals 
FIG. 2 shows in block diagram form, the access con- ^^^"^^^ different data values of set of commands 
trol processor (ACP) 10 of Uie preferred embodiment '"^'^f ^ ^l^"^^ ^ ^'^'^ 
As shown. ACP 10 includes a protected non-volatile ^ commands are an important 
memory 10-2. a random access memory (RAM) 104. a ^^e sets of comm^ds normally used by the 
microprocessor 10-6. an interval counter 10-8 and an ^ memory. The standard flash memory commands 
interface block 10-10 connected to bus 105. Non- ^L^iJ^^^ °^ commands utilized by the 
volatile memory 10-2 dedicates a number of addressed „ 28F001BX flash memory. Those commands are de- 
locations in which to store authentication information ^ publication entitled, "Memory Products." 
and programs. More specifically, memory locations P^^ished by Intel Corporation, referenced herein. The 
10-2a store one or more personal identification numbers pommands used by the present invention are described 
(PINs), protocol sequences or other identification infor. m Table 1. ^ ^, , ^ ^ 
mation for verifying that the user has access to the 40 '^^'c™^ to Table 1. the first command shown is a 
system, and for identifying the blocks in flash memories memory command which is used to initially 
103a through 103/1 that tiie user may access in addition ^ random number generated lock value into non- 
to a time interval value used for reauthcntication. volatile lock memory (LM) 35 in each memory 103a 
Memory locations l(^2b store the key values used for ^o^S^ 103«- Each memory 103a through 103n may 
protecting each of the flash memories 103a through 45 * different lock value or the same lock value de- 
103/j or the codes used to protect the individual blocks pending on the security needs of the users. The lock 
of each of the flash memories 103a through 103/t ^^^^ ^ loaded into LM 35 through key (K) register 31 
Memory locations 10-2c store the program instruc- control of the one bit, non-volatile storage ele- 
tion sequences for performing the required authcntica- ^* storage enable command of 
tion operations and for clearing the system if the preset ^ "^^^'^ ' ^ ^ storage element 36. This pre- 
conditions for failure are met. Certain program instruc- ^^n^s the lock value stored in LM 35 from being 
tions enable the user to control the setting of the inter- changed since storage element 36 once reset by the reset 
val counter 10-8 which establishes when user re-authen- storage enable command cannot be set. The non- 
tication takes place. The reauthcntication interval de- volatile contents of LM 35 are transferred to the L 
fines the time between interruptions and for sending an register 33 on power-up. It will be noted that the loca- 
intemipt to the host processor 5 requiring verification ^on or site of lock memory 35 is design dependent. For 
of the user's identity by having the user reenter the PIN example, memory 35 could be implemented as an exten- 
or other password. The interval counter 10-8 receives sion to memory array 54. 

clock pulses from the host processor 5 over bus 102 and ^ The load key register cotnmand of Table 1 is used to 

can be set by the user according to the work environ- load the key register 31 and set the delay counter 32. 

ment. For example, at home, the user may turn the timer The decrement delay counter command is used by the 

off (i.e., set it to 8 maximum value) . or set the time ACP 10 to decrement by one, the contents of the delay 

interval to one hour. On an airplane the user may set it counter 32. The read allow memory bank and read 

for ten minutes for increased protection. As described 65 disable memory bank commands are used by the ACP 

herein, the user is prompted to re-examine the setting of 10 to enable or disable access to the different memory 

this interval at every "power on" thereby forcing peri- blocks of memory array 54 during loading of the access 

odic re-authentications to enforce security. control memory 43. 
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TABLE 1 



rint Bus Cycle 
Operation 

Address Data 

Second Bus Cydc 
Operation Address 

Data 


Write 

31H 

Write 

N/A 

Memory 



Reset Lock 

Write 

33H 

N/A 

N/A 

Stonge Enible 



LoAdKey 

Write 

32H 

Write 

Key Data 

Register 




Decrunent De> 

Write 

35H 

N/A 

N/A 

by Counter 



Rod-Allow Xlem. 

Write 

MBA 34H 

Write 

MBA 

ory Bank 



Read-Diuble 

Write 

MBA 38H 

Write 

MBA 

Memory Bank 




LcMdLockMeaoryplH) 

TUloaaimaodoopia the oontciti of the key register 31 isto the ooo*vobaik kick meoorySSiftod only if tlie 
kick itonge enable 36 oatpm gigul b TRUE. 
Raet Lock Stonge Eiuble (33H} 

Tbm cnmmirwl retets the kick ttonge eniUe logic dement 36> thai inhlbttiiis Icadiu or r-h«T«jm; the ki^ 
fuinge acmory 3). 
LoKl Key Rcgiiter 02H) 

Thk ooeimaad tMfU the prior oootents of the key register 31, one byte (LSB towird MSB) and kwb "Key 
VatBc" from ACP 10 fato the key icsister LSB. Fttnber, it tea the Delay Cocster 32 to its manmani valne. 

«U ONES. 
Decremeiit Delay Coanter C35H) 

Thift oommiTwl decremcDti the delay coaster 32 by ONE. The delay oouoter masi equal ZERO to allow 
ssbaequeol readias of the SMmoiy array 54, 
Read-AOow Memory Bank (34H) 

TUf oomnuod aeu the bit corretpoodins to the memory bank addrm (MBA) b the a^^ 

if aad only if the acccn modificatioo allowed dgnal 37 b TRUE. Tbb allows read aocot to the Klected buL 

RcMl-Dbable Memory Bank (38H) 

Thb ooomaad reieu the bit cortespoodiag to the memory bank addim io the aoceo oootrol memory 43. 


Considering Table 1 in greater detail, it is seen that 
Table 1 also shows the bus cycle operations for each of 50% chance of success. This would require 231 x212 

the added commands. For each cotnmand requiring two 30 microseconds or 102 days to guess the key value. This 

bus cycles, during each first bus cycle, the command time is sufficient to deter most thieves. Of couree, a 

register 50 receives an 8-bit conunand generated by longer or shorter time could be provided by modifying 

ACP 10, sent via the data bus lOSa of bus 105 and an the sizes of the key and delay counter 32. 

input buffer 51. Conunand register 50 conditions the In the case where the memory card of the present 

selected logic element to receive from data bus 105fc» 35 invention is stolen and is put into an "outlaw host," the 

the information required to execute the command dur- ACP 10 lunits the number of tries by the thief to guess 

ing a second bus cycle. As indicated, the second bus the PIN by known techniques. Such techniques may 

cycle is designated not applicable (N/A) since the reset include locking access or destroying data if a threshold 

lock storage enable and decrement delay counter com- of incorrect guesses is exceeded, 

mands need only one cycle for execution. 40 During an initial authentication operation for flash 

During normal operation, the K register 31 is loaded memory 103fl. a key value is loaded into the 32 bit K 

wath the key value received from memory locations register 31 in response to four successive load key regis- 

10-26 by a load key register command and delay ter commands (i.e.. data bus 1056 is a byte wide bus), 

counter 32 is set to its maximum value. Delay counter Delay counter 32 is forced to its mnTifniim count of 

32 is decremented to all ZEROS in response to succes- 45 (ALL ONE'S) and decremented by the ACP 10 send- 

sive decrement delay counter commands received from ing decrement delay counter commands on successive 

the ACP 10 and generates a zero count output signal 41 first bus cycles. When the delay counter 32 is decre- 

which is applied as an input to AND 34. mented to ZERO, it generates the zero count signal 41 

Each delay counter 32 limits the number of tries or which is applied to one input of AND gate 34. 

attempts which can be made to access the flash memo- 50 If the key value stored in the K register 31 equals the 

ries 103a through 103n in the case where a thief re- lock value stored in the corresponding L register 33 

moves the chips and places them upon the "outlaw indicating that the user provided the proper idcntifica- 

card" and programs a processor or equipment to repeat- tion to the host processor 5, then compare logic 39 

edly try to guess each memory chip's key. Stated differ- applies an equals compare signal 42 to another input of 

ently, counter 32 ensures that a significant number of 55 AND gate 34. This causes AND gate 34 to generate an 

tries or attempts must be made in order to gain illegal access modification allowed signal 37 at its output, 

access to the flash memories. The key and delay counter which enables -writing to access control memory 43, 

sizes are selected to require such testing to take an un- under the control of ACP 10. This, in turn, subsequently 

reasonable amount of time. allows the reading of memory array 54. 

More specifically, the Key Register 31 stores approx- 60 The access control memory 43 contains volatile stor- 
imaiely 4 biUion (232) different combinations. In the age ofone bit for each block/bank ofthe memory array 
preferred embodiment, the delay counter 32 is a twelve- 54. These bits arc cleared to ZERO as part of the flash 
bit counter. Assuming the delay counter 32 is decre- memory's power up sequence. In order for data to be 
mented once each microsecond, it will require 2^2 or 4 read from the memory 103ft the bit corresponding to 
milliseconds per attcmpi at guessing the key value. The 65 the addressed memory block must be at logical ONE. 
ACP 10, knowing the correct key value, incurs only a These bits are set by the ACP 10 issuing read-allow 
four millisecond delay in the initial setup. Random at- memory bank commands if and only if the access modi- 
tempts to guess the key value will require 23» tries for a fication allowed signal 37 is TRUE. 
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As shown in Table 1, during the second bus cycle of enabled. That is, when lock register 33 contains "ALL 

the read-allow memory bank command, the three (3) ONES/* this generates a signal from ALL ONES de- 
high order address bits of the selected memory bank of tector element 38 to the OR gate 45 to enable the output 

memory array 54 are sent over address bus 105c as weU buffer 52. This effectively places flash memory 103fl in 

as a repeat of the hexadecimal conmaand identifier being 5 nonrsecure mode. This allows all of the security logic 

sent over the data bus 105a to command register 50. circuits of the present invention to be bypassed. Hence, 

This results in a ONE being written into the addressed the same flash memory chip can be used for both secure 

bit location in access control memory 43. In the pre- and non-secure applications, thus resulting in produc- 

ferred embodiment, the read-allow memory bank com- tion economies, 

mand sequence is repeated eight times since the mem- 10 

ory array 54 is orgaiized into eight banks of 16K bytes Memory Basic Logic Circuits 
each, llie ACP 10 may restrict access to selected banks As shown in FIG. 3, such circuits include a memory 
by issuing a sequence of read-disable memory bank array 54, a command register 50, input/output logic 
commands in a similar manner. circuits 60, an address latch 56, a write sute machine 61, 
The output of the access control memory 43 of the 15 erase voltage system 62, an output multiplexer 53, a data 
present invention is applied as an enabhng input to out- register 55, input buffer 51. output buffer 52 and a status 
put buffer 52 during each flash memory read cycle register 58, as shown. The basic logic circuits of flash 
when the contents of a location of any bank of memory memory 103a as discussed above, takes the form of the 
array 54 is being read out That is, a read cycle may type of circuits mcluded in the flash memory designated 
occur, however, the data read out is inhibited from 20 as 28F001BX manufactured by Intel Corporation. Since 
passing through output buffer 52 in the absence of the such circuits are conventional, they will only be de- 
appropriate bank's access control memory gating signal. scribed to the extent necessary. For further information 
More specificaDy, in the case of the preferred embodi- regarding such circuits, reference may be made to pages 
ment, access control memory 43 includes eight individ- 3-109 through 3-134 of the publication entitled, "Mcm- 
ually addressable bit storage elements, an input address 25 ory Products." order Number 210830, publishwi by 
3 to 8-bit decoder connected to the input of each storage Intel Corporation, dated 1992. As shown in FIG. 3, the 
element and a 1 to 8 output multiplexer circuit con- flash memory basic circuits receive a number of input 
nected to the output of each storage element. The three signals (A0-A16), address, data signals (D00-D07) and 
high order address bits of each address are decoded and control signals (CE, WE, OE, FWD and VPP). These 
used to select the storage element for the block whose 30 signals are described below in Table 2. 

TABLE 2 

Signil Descriptions 

Symbol Name >nd Function 

A0.A16 ADDRESS INPUTS for memory iddresses. 

Addresses are interTully latched during a 
write cycle. 

D0Q.DO7 DATA INPUTS/OUTPUTS: Inputs dau and commands 
during memory write cycles; outputs data 
during memory and status read cycles. The 
data pins are active high and float to tri- 
sUte off when the chip is deselected or the 
outputs are disabled. DaU is internally 
latched during a write cycle. 

CE CHIP ENABLE: Activates the device's control 

logic, input bufTers, decoders and sense 
ampUBera. CE is active low, CE high 
deselects the memory device and reduces power 
c»nsamption to standby levels. 

PWD POWERDOWN: Putt the device in deep powerdown 

mode. PWD s active low; PWD high gates normal 
operatibn. PWD<kVHH allows programming of the 
memory blocks. PWD also locks out erase or 
write operations when active low, providing 
dau protection during power transitions. 

OE OUTPUT ENABLE: Gates the device's outpuU 

through the data buffers during a read cycle. 
OE is active low. 

WE WRTTE ENABL& Controls writes to the command 

register and array blocks. WE is active low. 
Addresses and data are latched on the rising 
edge of the WE pulse. 

Vpp ERASE/PROGRAM POWER SUPPLY for erasing blocks 

of the array or programming bytes of each 
block. Note: With Vpp < Vppl Max, memory 
contents cannot be altered. 


contents are to be changed. Similarly, the same three 
bits are used to select the output of the storage element 
for the block containing the flash memory location 
being read. 65 

If the lock memory 35 is fully erased, i.e., at ALL 
ONES as indicated by the contents of the L register 33 
being at all ONES, then the output buffer 52 is always 


As shown in Table 2, the Chip Enable (CE), Write 
Enable processor (WE) and Output Enable (OE)) sig- 
nals are applied to command register 50 and I/O logic 
60 from host processor 5, via bus 102 and control bus 
1056 and are dispersed to control specified logic blocks. 
A powerdown (PWD) signal is also applied to com- 
mand register 50 for enabling the flash inemory to per- 
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form the operations specified in Table 2. This signal can tion for a period of time following loading to make 
be used to clear the volatile storage elements of the flash random tries an unproductive process. Loading of the 
memory's security control section as desired thereby key registers causes the "access modification allowed" 
enforcing user rcauthentication when nonnal operation signal to be true in each chip. The ACP 10 then estab- 
is again resumed. 5 lishes access by loading the access control memories 

Generally, the basic logic elements of the flash mem- according to the stored information configuration, 
ory operate in the following manner. Information is As a sixth step, at subsequent authentication dialog, 
stored in memory array 54 via data bus 105* input periodically, according to the user's configuration, the 
buffer 51 and data register 55 at an addressed location of ACP 10 prompts an additional user authentication 
one of the memory blocks specified by the address re- 10 (rcauthentication). In the event of failure, the ACP 10 
ceived by an address logic 56 from address bus 105c forces all memory chips to their power on states, thus 
Information is read from a specified address location of inhibiting any access to the memories' data by clearing 
a bank of memory array 54 and is sent to host processor the access control memory 43 and clearing the contents 
5 via an output multiplexer 53, output buffer 52, data of the key register 31. Now, the operation of the system 
bus 105a and bus 102. Status register 58 is used for stor- 15 of FIG. 1 wiU be described with reference to FIGS. 4 
ing the status of the write state machine, the error sus- and 5. 
pend status, the erase status, the program status and the 

Vpp status. First Operations of the Day 

The write state machine 61 controls the block erase FIG. 4 shows in block diagram form, the various 
and controls program algorithms. The program/erase 20 modes of operation. Blocks 402 and 401 show the two 
voltage system 62 is used for erasing blocks of the mem- startup conditions. In block 402, the user inserts the 
ory array 54 or the programming bytes of each block as memory card 3 in the previously powered-up host pro- 
a function of the level of Vpp (i.e., when Vpp is at a cessor 5. In block 401, the user powers up host proces- 
high level programming can take place; if Vpp is at a sor 5 with memory card 3 already installed, 
low level, memory array 54 functions as a read only 25 In either of the above startup operations, during 
memory). block 402, the ACP 10 and its interfaces are initialized in 

DESCRIPTION OF OPERATION a conventional manner^^ and block 403 clears all of the 

71 K registers 31 and the 'n' access control memones 43 

The operation of the secure memory card of the pres- as part of the flash memories 103fl throu^ 103n interna! 
cnt invention will now be described with particular 30 initialization sequence. This prevents any data from 
reference to the flow diagram of FIGS. 4 and 5. Before being read out of memories 103<2 through 103/i since 
describing such operations in detail, the steps involved output buffer 52, in each memory, is disabled. The lock 
in the fabrication, customization and operation of the value is loaded into the *n' L registers 33 from the re- 
memory card will fu^t be described. spective LMs 35 as a result of power on. 

As a first step, at card fabrication, the ACP 10 sets the 35 Now in block 404, ACP 10 sends an interrupt signal 
lock value for each of the memory chips on the memory to host processor 5 which responds by requesting the 
card. It does this by loading the key value into the lock PIN or other identifying information from the user. In 
memory of FIG. 3. These values are stored in the block 405, ACP 10, by means of the program stored in 
ACP's protected non-volatile memory 10-2 (i.e., keys memory locations 10-2a; checks that the PIN or other 
1-n in FIG. 2). The lock storage enable elements 36 are 40 identifying information matches the information stored 
then set to ZEROs to inhibit further changing or read- in memory locations 10-2a. If no match, then decision 
ing of lock memory contents. As these elements are block 406 counts an error and ACP 10 branches to 
nonvolatile, they cannot be changed unless the entire block 404 to repeat the test. If the test fails a preset 
flash memory chip is cleared. number of times, then decision block 406 branches to 

As a second step, at application customization, since 45 block 407 to cause ACP 10 to cither lock up or destroy 
writing is not affected by the protection functionality, the contents of the memories 103<2 through 103/t 
the memory card can then be loaded with its data or 

software application. The ACP 10 is then loaded with ^^er Authentication Successful 

information pertaining to the memory's bank structurie If in decision block 406 there is a match indicating a 
and the degrees of protection which are to be applied to 50 successful authentication then in block 408, the ACP 10 
each memory bank. via a load key register command loads each K register 

As a third step, at user customization, the user csub- 31 from memory locations 10-2A with the appropriate 
lishes parameters for the frequency and mode of authcn- key value. Also block 409 repeatedly decrements the 
tication and specific data required (e.g., personal identi- contents of delay counter 32 issuing successive the dec- 
fication numbers (PINs)). This information is stored in 55 rcment delay counter commands toward a binary zero 
the ACP'S memory. count which causes the generation of the zero count 

As a fourth step, at power on, the "key register", signal 41 in FIG. 3. 
"access modification allowed" sigjial and "access con- In block 410, each access control memory 43 location 
trol memory" are initialized so as to inhibit access to is loaded with information by means of the read-allow 
data or writing to access control memory 43. The first 60 memory bank command to allow access to the selected 
authentication dialog is initiated. banks of the corresponding flash memory 103fl through 

At first authentication dialog, the ACP 10, using the 103/1. 
services of its host processor 5, prompts the user and 

receives authentication information. If authentication is Intermittent Re-authentication 

unsuccessful, no operation is performed; if successful, 65 In block 411, the ACP 10 awaits the end of the preset 
the key register of each memory chip is loaded with the time interval established by information stored in mem- 
value stored in the ACP'S memory. During this opera- ory locations 10-2a signalled by interval counter 10-8 
tion, the delay counter 32 is used to inhibit chip opera- before requesting user re-authentication. Then, in block 
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412, the ACP 10 interrupts the host processor 5 to re- microprocessor for receiving said address, data and 
quest the user to re-enter the PIN or other required control information, said memory including a non- 
identification, volatile memory section and a security control 
Decision block 413 checks the PIN or other infoima- section, said memory section containing a memory 
tion received from the host processor 5 against the 5 array organized into a number of blocks, each 
information stored in memory locations 10-2fl and the block having a plurality of addressable locations 
interval timer 10-8 output is recorded. The user has a and control logic means for performing said mem- 
preset time interval of typically 30 seconds in which to ory operations and said security control section 
enter the authentication information into host processor being connected to said internal bus, to said control 
5. While the clock is running, if the decision block 413 10 logic means and to said methory array, said secu- 
test fails, then block 414 records the test as an error. At rity control section including: 
that time, it checks if a m a x i m u m number of errors was a number of non-volatile and volatile storage devices 
received and branches to repeat blocks 412 and 413. If for storing at least one of said key values and con- 
the number of errors equals the maximum number, then figuration information associated with said blocks; 
in block 415, APC 10 clears the flash memory K register 15 and, 

31 by means of successive load key register commands, access control logic means connected to said control 

and clears the access control memories 43 with succes- logic means and to said storage devices, said access 

sivc read-disable memory commands. Block 415 then control logic means enabling reading of informia- 

branches to block 404 to allow a new *Tirst Authentica- tion stored in addressed ones of said blocks of said 

tion" operation to take place. 20 memory array as specified by said configuration 

If the test in decision block 413 is successful, the K information only after said microprocessor has 
register 31 remains unchanged (i.e., contains the key determined that a predetermined authentication 
value previously loaded by the ACP) enabling the user procedure has been performed with said host corn- 
to continue to operate the system 1. In the event that the puter and has enabled said access control logic 
30 seconds elapsed without decision block 413 receiving 25 means for allowing reading of said information 
the PIN or other information, the ACP 10 clears the K from said memory array according to said configu- 
register 31 and the access control memory 43 as before. ration information. 

FIG. 5 is a flow diagram which illustrates how host 2. The memory card of claim 1 wherein said micro- 
processor 5 responds to an interrupt request from APC processor and said non-volatile memory arc included on 
10 for authenticatipn in response to blocks 404 and 412 30 separate semiconductor chips, 
of FIG. 4. As shown, decision block 501 is waiting for 3. The memory card of claim 1 wherein said card 
an interrupt from the ACP 10 requesting that the user further include interface circuit means coupling said 
re-enter the PIN or other information. Decision block card to said host computer and wherein said interface 
501 branches to block 502 when it receives the interrupt circuit means and said microprocessor are included on 
from blocks 404 or 412. Block 502 displays the request 35 the same semiconductor chip, 
for the PIN or other information on host display 5-2. 4. The memory card of claim 1 wherein said non- 
Block 503 accepts the information from the keyboard volatile memory and said non-volatile storage devices 
and block 504 interrupts ACP 10. Block 5 sends the PIN are flash memories. 

to ACP 10. 5. The memory card of claim 1 wherein one of said 

It will be appreciated by those skilled in the art that 40 non-vohtile storage devices is a lock memory for stor- 

many changes may be made to the preferred embodi- ing a lock value corresponding to said one key values 

ment of the present invention without departing from its and a second one of said non-volatile devices is a lock 

teachings. For example, the invention may be used with storage enable element which connects to said lock 

clifferent types of non-volatile memories and different memory, said lock memory being initially loaded with 

interfaces, etc. 45 said lock value and said lock storage enable element 

While in accordance with the provisions and statutes being switched to a state which inhibits modification of 

there has been illustrated and described the best form of said lock value under control of said microprocessor, 

the invention, certain changes may be made without 6. The memory card of claim 2 wherein storage of 

departing from the spirit of the invention as set forth in said lock value and switching of said lock storage en- 

the appended claims and that in some cases, certain 50 able element takes place during initial fabrication of said 

features of the invention may be used to advantage memory card. 

without a corresponding use of other features. 7. The memory card of claim 5 wherein one of said 

What is claimed is: volatile storage devices is an addressable access control 

1. A secure memory card for use with a host portable memory having a plurality of locations corresponding 

computer, said memory card comprising: 55 in number to said number of blocks of said memory 

a microprocessor connected for transmitting and array for storing said conflgiiration information, said 

receiving address, data and control information to access control memory being connected to said internal 

and from said host computer and said microproces- bus and to said access control logic means, said access 

sor including: control memory being loaded under control of said 

an addressable non-volatile memory for storing infor- 60 microprocessor only after said microprocessor has de- 

mation including a number of key values and con- termined that said predetermined authentication proce- 

figuration information; dure initially has been successfully performed with said 

an internal bus connected to said microprocessor for host computer earning enabling of said access control 

transmitting address, data and control information memory by said access control logic means, 

defining memory operations to be performed by 65 8. The memory card of claim 7 wherein said lock 

said card; and, value loaded into said lock memory is all ONES and 

at least one non-volatile addressable memory being wherein said security control section further includes an 

connected to said internal bus in conunon with said all ONES detector circuit connected to said lock mem- 


02/20/2004, EAST version: 1.4.1 


15 


5,293,424 


ory, said detector circuit in response to said lock value 
of all ONES generating a signal which effectively by- 
passes said security control section enabling said non- 
volatile memory to operate as if said security control 
section had not been included. 

9. The memory card of claim 7 wherein performance 
of said predetermined authentication procedure initially 
takes place when said memory card is first connected to 
communicate with said host computer. 

10. The memory card of claim 9 wherein said access 
control means includes a lock register connected to 
receive said lock value from said lock memory, a com- 
parator circuit, a key register for storing a key value 
transferred to said key register by said microprocessor, 
a delay counter for storing a count defining a predeter- 
mined time interval and gating means connected to said 
access control memory, to said comparator and to said 
delay counter, said comparator circuit being connected 
to said lock and key registers and to said gating means 
and said gating means being connected to said delay 
counter for generating an access modification allowed 
signal in response to said comparator circuit signalling 
an identical comparison between said lock code value 
loaded into said lock register when said delay counter 
has signalled an end of said predetermined time interval, 
said access modification allow signal conditioning said 
access control memory for loading said configuration 
information. 

11. The memory card of claim 10 wherein said con- 
trol logic means includes circuits for generating com- 
mand signals in response to a predetermined set of com- 
mands used by said microprocessor in controlling the 
operation of said security control section of each mem- 
ory chip. 

12. The memory card of claim 11 wherein said con- 
trol logic means in response to a first one of said prede- 
termined set of commands generated by said micro- 
processor, generates a first signal for loading said lock 
code value into said lock memory, said first one of said 4q 
predetermined commands being generated during initial 
fabrication of said card. 

13. The memory card of claim 12 wherein said con- 
trol logic means in response to a second one of said 
predetermined set of commands generated by said mi- 
croprocessor generates a second signal for switching 
said lock storage enable element to a predetermined 
state which inhibits said reading or said modiHcation to 
said lock value stored in said lock memory. 

14. The memory card of claim 12 wherein said con- 50 
trol logic means in response to a third one of said prede- 
termined set of commands generated by said micro- 
processor, generates a third signal for loading said key 
register with a predetermined one of said key values, 
said third one of said predetermined set of commands 55 
being generated by said microprocessor only after said 
microprocessor has determined that said predetermined 
authentication procedure has been successfully per- 
formed. 

15. The memory card of claim 14 wherein said third 60 
signal generated by said control logic means simulta- 
neously forces said delay counter to a predetermined 
count for establishing a start of said predetermined time 
interval and wherein said control logic means in re- 
sponse to each fourth one of said predetermined set of 63 
commands generated by said microprocessor decre- 
ments by one, said predetermined count, said delay 
counter signalling said end of said time interval follow- 
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ing execution of a predetermined number of said fourth 
ones of said set of predetermined conmiands. 

16. The memory card of claim 11 wherein said con- 
trol logic means in response to a number of fifth and 
sixth ones of said predetermined set of commands by 
said microprocessor, generates fifth and sixth signals for 
setting and resetting locations in said access control 
memory according to said configuration information 
for defining which ones of said blocks from which infor- 
mation is allowed to be read out. 

17. A secure memory card installable in a host porta- 
ble computer for establishing communication with said 
host computer, said memory card comprising: 

a microprocessor contained on a single semiconduc- 
tor chip, said microprocessor being connected for 
transmitting and receiving address, data and con- 
trol information to and from said host computer 
and said microprocessor including: 
an addressable non-volatile memory for storing infor- 
mation including a number of key values defining 
user accessibility to memory areas, and memory 
configuration information defining memory read 
^out accessibility to said memory areas; 
en internal bus for transmitting address, data and 
control information defining memory operations to 
be performed by said card; and, 
at least one non-volatile addressable memory chip 
being connected to said internal bus in common 
with said microprocessor for receiving said ad- 
dress, data and control information, said memory 
chip including a memory section and a security 
section, said memory section containing a non- 
volatile memory array having a data output and 
being organized into a number of blocks, each hav- 
ing a plurality of addressable locations and control 
logic means for performing said memory opera- 
tions, said security section being connected to said 
internal bus, to said control logic means and to said 
data output and said security section including: 
a non-volatile lock memory coupled to said inter- 
nal bus for initially receiving and permanently 
storing a predetermined lock value which 
matches one of said number of key values; 
access control logic means connected to said con- 
trol logic means and to said lock memory for 
generating an enabling signal upon detecting 
when said predetermined lock code value identi- 
cally matches a selected one of said key values 
applied by said microprocessor to said internal 
bus; and, 

an addressable volatile access control memory 
having a plurality of locations corresponding in 
number to said number of blocks of said memory 
array for storing said memory configuration 
information defining said read out accessibility, 
said access control memory being connected to 
said control logic means, to said memory array 
data output, to said internal bus, and to said ac- 
cess control logic means, said access control 
logic means enabling reading of information 
stored in addressed ones of said blocks of said 
memory array as specified by said memory con- 
figuration information only after said micro- 
processor has determined that a predetermined 
authentication procedure has been successfully 
performed with said host computer and has 
transferred said predetermined one of said mem- 
ory key codes causing said access control logic 
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means to generate said enabling signal for appli* 
cation to said data output for enabling reading 
out said information to said data output as speci- 
fied by said access control memory configura- 
tion information. 

18. A secure memory card including a number of 
non-volatile memory chips, each memory chip includ- 
ing a memory array organized into blocks of address- 
able locations, having a capability of operating' in a 
number of modes, said card comprising: 

a lock memory for storing a lock value; 

control means for generating first and second com- 
mands and a predetermined key value; 

a key register coupled to said control means and 
responsive to said first command for storing said 13 
predetermined key value; 

a comparator coupled to said lock memory and to 
said key register, said comparator generating a 
compare signal whenever said lock value and said 
predetermined key value are equal; 

a delay counter coupled to said generating means and 
responsive to said first command for setting said 
counter to a maximum count value, and responsive 
to a sequence of successive second commands for 
generating a zero count signal when said delay 23 
counter has been decremented to zero; 

logic circuit means coupled to said comparator and to 
said delay counter, said logic circuit means respon- 
sive to said compare signal and said zero count 
signal for generating an access modification al- 
lowed signal; 

said control means for generating a third conunand, 
and first address signals and subsequent address 
signals identifying a first of said blocks and subse- 
quent blocks respectively; and, 

access control memory means being coupled to said 
logic means and to said control means, said access 
control memory responsive to said access memory 
enable signal, said address signals and said third 
command for storing indications signifying when 40 
said one of said blocks and said subsequent blocks 
are enabled for reading. 

19. The system of claim 18 wherein said predeter- 
mined value and maximimi values are selected to be 
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memory chip including a memory array organized into 
blocks of addressable locations and control logic cir- 
cuits for generating command signals for performing 
memory operations, said method comprising the steps 
of: 

(a) incorporating a microprocessor into said card 
which is connected to communicate with said host 
computer when installed therein, said microproces- 
sor including an addressable non-volatile memory 
for storing information including a number of key 
values defining user accessibility to memory areas 
and memory configuration information defining 
accessibility to said memory areas; 

(b) incorporating security logic circuits into each 
non-volatile memory chip, said security logic cir- 
cuits including a non-volatile lock memory for 
storing a predetermined lock value, access control 
logic means connected to said lock memory and an 
addressable volatile access control memory having 
a plurality of locations corresponding in number to 
said number of blocks for storing accessibility bit 
information according to said configuration infor- 
mation; 

(c) interconnecting said microprocessor to each 
memory chip for transferring address, data and 
control information to said each memory chip; 

(d) modifying said control logic circuits to be respon- 
sive to a jplurality of commands for operating said 
security logic circuits; 

(e) connecting said microprocessor for performing an 
initial preestablished user authentication operation 
with said host computer; and, 

(0 connecting said security logic circuits to be en- 
abled by said microprocessor transferring specific 
ones of said plurality of commands to said each 
chip only when said authentication operation in 
step (e) has been successfully performed for allow- 
ing said information stored in different ones of said 
blocks to be read out according to said accessibility 
bit information stored in said access control mem- 
ory. 

24. The method of claim 23 wherein said micro- 
processor non-volatile memory has a number of sec- 
tions and wherein said key values are provided by gen- 


sufficiently large so as to prevent ease of access to said 45 crating random values for said key values which are to 
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information stored in said non-volatile memory when 
said memory card is placed in an unauthorized host 
computer. 

20. The card of claim 18 wherein said control means 
includes a microprocessor which couples to said mem- 
ory which, upon successfully performing a first user 
authentication operation, generates said first, second 
and third commands. 

21. The card of claim 20 wherein said first cohunand 
is a load key command, said second coounand is a dec- 
rementing command and said third command is a read 
allow block conunand. 

22. The card of claim 18 wherein said memory fur- 
ther includes command control means for decoding a 
predetermined set of commands for conditioning said 60 
card to perform normal memory operations, and said 
command control means including means for decoding 
an additional set of conmiands including said first, sec- 
ond and third commands for providing security for 
information stored in said memory. 

23. A method of organizing for operation, a secure 
memory card installable in a host computer which in- 
cludes a number of non-volatile memory chips, each 


65 


be loaded into a first one of said number of sections. 

25. The method of claim 23 wherein said method 
further includes the steps of: (g) including an interval 
counter in said microprocessor; (h) connecting said 
interval counter to said microprocessor non-volatile 
memory and said interval counter being loaded with a 
value corresponding to a user selected time interval; 

(i) connecting said microprocessor for periodically 
initiating said user authentication operation of step 
(e) at said user selected time interval; and, 

(j) connecting said security logic circuits to be en- 
abled for continuing to allow said information 
stored in said blocks to be read out according to 
said accessibility bit information as long as said 
authentication operation of step (e) is successfully 
performed. 

26. A method of constructing a secure memory card 
which includes a number of non-volatile memory chips 
for storing large quantities of information, each memory 
chip including a memory array organized into blocks of 
addressable locations and control logic circuits for gen- 
erating command signals for performing memory oper- 
ations, said method comprising the steps of: 
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(a) incorporating a microprocessor into said card, 
said microprocessor including an addressable non- 
volatile memory for storing information including 
a number of key values defining user accessibility 
to memory areas and memory configuration infor- 
mation defining accessibility to said memory areas; 

(b) incorporating security logic circuits into each 
non-volatile memory chip, said security logic cir- 
cuits including a non-volatile lock memory for 
storing a predetermined lock value, access control 
logic means connected to said lock memory and an 
addressable volatile access control memory having 
a plurality of locations corresponding in number to 
said number of blocks for storing user accessibility IS 
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bit information in accordance with said configura- 
tion information; 

(c) interconnecting said microprocessor to each 
memory chip for transferring address, data and 
control information to said each memory chip; and, 

(d) modifying said control logic circuits to incorpo- 
rate a plurality of commands for operating said 
security logic circuits as an extension to a set of 
commands normally provided by said control logic 
circuits whereby said security logic circuits protect 
said information contained in said number of chips 
from being read out in an unauthorized manner 
even when said chips are removed from said mem- 
ory card. 
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